Worker consumes a cpu core if it receives broken pipe.

[purge]

Summary

Running worker in library mode with noHandleSignals: false, worker will consume 100% cpu if the terminal goes away (and triggers SIGPIPE).

Steps to reproduce

kill workers output terminal

Expected results

not making my laptop warm

Actual results

warm laptop which is nice in winter but not good in summer

Additional context

Possible Solution

Handle SIGPIPE in handlers

[benjie]

From DMs with @purge this might be specific to the way that VSCode terminates consoles, might need to use a VSCode terminal to reproduce. Or just issue SIGPIPE I guess - e.g. pipe it through tee and then kill tee and see what happens.

[purge]

i just tried with tee and it does cause the issue in a repeatable way, though you have to trigger more console output for worker once you've killed the tee process for it to happen.

[benjie]

When I just run graphile-worker -c ... | tee /dev/null and kill tee I end up with:

node:events:496
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at afterWriteDispatched (node:internal/stream_base_commons:160:15)
    at writeGeneric (node:internal/stream_base_commons:151:3)
    at Socket._writeGeneric (node:net:952:11)
    at Socket._write (node:net:964:8)
    at writeOrBuffer (node:internal/streams/writable:564:12)
    at _write (node:internal/streams/writable:493:10)
    at Writable.write (node:internal/streams/writable:502:10)
    at console.value (node:internal/console/constructor:304:16)
    at console.log (node:internal/console/constructor:379:26)
    at Logger.log (/home/benjie/Dev/graphile/worker/node_modules/@graphile/logger/dist/index.js:84:28)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:169:8)
    at emitErrorCloseNT (node:internal/streams/destroy:128:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -32,
  code: 'EPIPE',
  syscall: 'write'
}

The system exits due to the unhandled error. This isn't great, but it also isn't consuming a CPU core. Perhaps you have an unhandled error handler that itself logs, causing a cycle? This doesn't seem to be specifically a Worker issue.