A Stado that stops on every start

A Stado that stops on every start

A stado serve that fails — a component stopped, or its start could not finish — appends the stop to ~/.stado/serve-stops.jsonl before it exits: {version, revision, at, failure, reported, report}, with the version and source revision of the binary that stopped. A build that stops again on the same host is a failed install, not a restart to wait out: on its second stop Stado runs oko defects record --product stado once for that build, titled “Stado VERSION stops on every start on HOST: FIRST LINE OF THE FAILURE”, found in stado serve VERSION on HOST (a host Stado serves on holds no checkout Oko could verify a revision against, so the revision is the evidence's first line), with every stop and its failure as evidence, and keeps what Oko answered on that stop (report): recorded: … marks it reported; oko defects record ended STATUS: STDERR or could not run: CAUSE leaves it unreported, says the cause on stderr, and the next stop of the build tries again. Oko is run from ~/.stado/bin/oko, where a Stado product install places it, because the service unit that runs stado serve has no login PATH; a host without Oko there reads oko defects record could not run: ~/.stado/bin/oko is installed at none of its declared paths: HOME/.stado/bin/oko. Once a stop is reported, later stops of the build are kept and raise nothing, so a crash loop is one defect, not one per restart; a new build starts over. No count or window is Stado's: the second stop of a build is the measurement. A stop that cannot be kept is said on stderr as stado serve's stop could not be kept: CAUSE beside the service's own failure, which it never replaces. The defect is read where every defect is, oko defects list and Oko Desktop. stado resolver status shows the newest build that stopped on the host under serve_stops (--json: {version, revision, stops, first_at, latest_at, latest_failure, report, held}, null when stado serve never stopped there, {unreadable} with the cause when the kept stops cannot be read), printed as serve stops stado VERSION (revision REV) stopped N time(s), first T, latest T: FAILURE; defect: REPORT (the recorded defect, or while none is, why the newest attempt failed), followed by serve stops revision REV is held from source installs until the checkout moves past it when held is true (a stop of that revision raised the defect, the hold below); Stado Desktop's route operations read the same report as "Read this host's resolver".

When stado release local install activates a new image of the host's resident Stado, it first moves every stop kept in ~/.stado/serve-stops.jsonl to ~/.stado/serve-stops.handed-off.jsonl and says set aside N kept stop(s) of the replaced build in PATH. A Stado that predates the worker's clean release handoff ends its worker, when the installed release supersedes it, as a failed agent loop; with its earlier stops still kept that stop was a repeat, and it reinstalled the release the installation had just replaced. Set aside, the handoff is a first stop and measures nothing. A register that cannot be set aside refuses the install before the image changes: stado was not installed: the replaced build's stops could not be set aside, so its handoff would read as a crash loop and reinstall it: CAUSE.

A revision whose stops raised that defect is held from source installs on the host. After stado release local restore --previous puts a working build back, product sync's next pass would build the canonical checkout again — the commit that stopped on every start — so a source install of a revision with a reported stop in ~/.stado/serve-stops.jsonl or ~/.stado/serve-stops.handed-off.jsonl is refused before anything is exported: PRODUCT: revision REV is held: stado serve VERSION built from it stopped N time(s) on this host (PATH and HANDED-OFF PATH), the latest with: FAILURE; REPORT. A later commit is built as usual. A stop file that cannot be read refuses the install with whether revision REV is held cannot be told: CAUSE rather than building past it. The hold lifts by itself when the checkout moves to a commit with no reported stop; nothing has to be cleared by hand. STADO_BIN=<built stado> STADO_PRODUCT_TEST_PRODUCT=<product with a stado-release service recipe> STADO_PRODUCT_TEST_SOURCE=<its checkout> node tests/product/held/revision.mjs runs both refusals in isolated homes under .build/product-held-revision-* and keeps the commands, exit statuses and refusals in report.json.