A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I1992

A rebuild that fails consumes no change: the next request retries it

Where it stands

devtask.issue

Readiness: complete completion is recorded and every required evidence token is present
Status: DONE
Can start: not now
Milestone: development-runtime
Milestone status: ACTIVE
Wave: 0
Waiting on: none
Holds back: none
Behind it in all: 0
Evidence: 1 of 1

Moves

plan.transition

What it is

Objective: When a long-lived server's rebuild of its repository picture fails, keep the change it noticed unconsumed, so that a later request retries the load (bounded, not on every request) instead of serving the previous generation until git happens to move again.
Why: Found while closing the case 545 flake (fix/ci-flakes-545-and-multicast 79ecdbb944, batch B3 #788): Live::reload (apps/majordomus-cli/src/live.rs, the Err arm of `match built`) records `state.stamp = taken` when App::load fails, so the stamp the failed load was taken under now reads as current. A transient failure — a git process caught mid-write, an index.lock, a manifest saved half-way — therefore makes the server miss the commit that triggered it, and every answer (HTTP, MCP, Cockpit) keeps the old head with a fresh-looking observed_at until some unrelated move. The comment there gives the reason (not to retry a failing load on every request); the cost of that choice is a commit silently not seen. Case 545 now polls for the new head and prints the server's 'would not load' line when it fails, so an occurrence names this path.
Now: A failed App::load sets the generation's stamp to the stamp it was taken under: the change is consumed, and no request retries the load until the git control files move again.
Wanted: A failed load leaves the generation's stamp as it was and records the failure (stamp and moment) beside it; a request whose stamp equals the failed one retries the load once a bounded interval has passed since that failure, and is served the previous generation (with the failure said) inside it. A stamp that moves again retries at once. The warning names the retry.
Done when: unknown: the record declares no `completion`
Risk: unknown: the record declares no `risk`

Acceptance

A load that fails and then would succeed, with no further repository move, is retried after the interval and the next answer carries the new head
A load that keeps failing is attempted at most once per interval, not once per request
Case 545 still passes; with the retry removed, the new test fails

Validation: bin/majordomus plan validatecargo test --manifest-path apps/majordomus-cli/Cargo.toml --lib live::MJ_TEST_JOBS=4 bash test/run.sh 545_every_answer_says_when_it_was_observed
Evidence required: failed_load_is_retried_test
Evidence present: failed_load_is_retried_test

Scope

Touches: apps/majordomus-cli/src/live.rsapps/majordomus-cli/teststest/cases
Not: The stamp's watched files (WORKTREE_FILES, COMMON_FILES)The mid-rebuild rule: a request arriving during a rebuild is still served the existing generation
Depends on: unknown: the record declares no `depends_on`
Priority: p2
Profile: implementation
Parallel safe: true
Owner: unknown: the record declares no `owner`

The work so far

Branches: none
Merged: none
Commits: 0
Trunk: master
Sessions: none
Created: 2026-10-06
Updated: 2026-10-14T07:59:09Z
Started: 2026-10-14T07:59:03Z
Verified: unknown: the record declares no `verified_at`
Completed: 2026-10-14T07:59:09Z

Synchronisation

Adapter: scripts/github-sync
Repository: unknown: the derived plan's header carries no repository
External issue: unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
State there: unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.