MGS3030: pipe upstream failed

A shell reports a pipeline's status from its last stage only, unless set -o pipefail is on, and agents never turn it on. So a pipe of magus runs carries the status forward itself (see Piping one magus into another). Every magus stage whose stdout is a pipe records how it ended, and a run reading that pipe checks it twice.

Before it takes any lock, a run refuses to start after a proven upstream stage that has already failed:

[MGS3030] pid 40118 (magus run generate:rw libs/api), upstream of this run in a
  pipe, exited 1, so this run started nothing. A pipeline of magus runs stops at its
  first failed stage: fix that stage, then run the pipeline again.

A run that succeeded waits for every proven upstream stage to end before it exits, and fails with the first one that did not:

[MGS3030] pid 40118 (magus run build libs/api), upstream of this run in a pipe,
  exited 2. This run succeeded, but the pipeline failed at that stage.

The exit status is the upstream's own, or 1 when a signal stopped it. A run that failed reports its own failure instead. An upstream that ended without recording its status, because it was killed or ran against another workspace, is named on stderr as unknown and does not fail the run.

Resolution

• Fix the stage the message names, then run the pipeline again.
• Run that stage on its own to see its failure in full; its output went to stderr above the refusal.

See also

• MGS3023: a pipe whose writers loop back into the run reading it.
• Concurrency: how one magus waits on another it reads from.