[ndbroadbent]

See #1566.

Motivation

When a forked worker exits without reporting back, Parallel raises Parallel::DeadWorker and Tapioca prints only that error's backtrace, which doesn't say what happened or what to try. (A worker that raises a Ruby exception sends it back, and the parent re-raises it, so DeadWorker means the process was killed or crashed.) The usual causes are running out of memory and a native extension crashing after the fork. On macOS with PostgreSQL the second is common enough that the advice to set PGGSSENCMODE=disable has been given in #1555, #2241 and #2390.

Implementation

Executor#run_in_parallel turns Parallel::DeadWorker into a Tapioca::Error, which exe/tapioca prints without a backtrace:

A worker process exited before it finished. Tapioca forks 2 worker processes, and a worker usually
dies because the system ran out of memory, or because a native extension crashed in the forked process
(look above for a crash report, such as `[BUG] Segmentation fault`).

To do the work in a single process, which shows the error if there is one, run the command again with
`--workers=1`.

On macOS, a crash in the pg gem while it connects to PostgreSQL comes from libpq trying GSSAPI
encryption. Turn it off with `PGGSSENCMODE=disable` in the environment, or with
`gssencmode: disable` in config/database.yml.

The last paragraph appears only on macOS, with the pg gem loaded and PGGSSENCMODE unset. This covers the "at the very least" half of #1566; it doesn't recover the dead worker's own trace, which for a crash Ruby has already printed to stderr above the message.

Tests

Two executor specs: a worker that kills itself gives the message, and the PostgreSQL paragraph appears only when the check says it applies.