Skip to content

A failing setup stage reports its status and discards its reason #377

Description

@blooop

Question

A failing setup stage writes the sentence that says why to stderr — deliberately, so a developer can act on it (flows/provision.rs:1015-1022) — and nothing reads it. setup_pass captures both streams and reads only stdout for the probe report (flows/provision.rs:1944-1946); Answer::stderr() exists and five other devpod call sites read it. So StageFailed carries {workspace, stage, status, loudness} and renders as <ws>: the <stage> setup stage exited <status>. (dl/src/render.rs:2234-2240) — the status and no reason, every time.

This is what made #367 undiagnosable: the herdr stage refused for one readable reason (no python3 in the container), said so on stderr, and a launch printed only exited 1. That stage is gone in 0.12.0, but the hole is not herdr's — hostname, zellij and title all fail the same silent way. Carry the reason on StageFailed and render it.

Settle inside this ticket: attribution, which is the whole difficulty. One bash -lc runs every stage into one stderr stream, so a line is not labelled with the stage that wrote it — either the pass marks stage boundaries on stderr the way PROBE_MARK marks the report on stdout, or the event carries the pass's whole stderr once rather than per stage. Also whether the reason obeys FailureLevel (the hostname stage is quieter() because sudo hostname fails on most cold launches — its reason is noise, not news), and how much of a chatty stage's stderr is worth keeping: the zellij stage redirects a whole pixi install there, which is pages.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions