Skip to content
Cockpit0.29.0
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

I1502

A server serving code that no longer exists stops calling itself ready

Where it stands

devtask.issue
Readiness
complete completion is recorded and every required evidence token is present
Status
DONE
Can start
not now
Milestone
Milestone status
ACTIVE
Wave
0
Waiting on
none
Holds back
none
Behind it in all
0
Evidence
2 of 2
A move writes the repository: it stamps one field of this issue's record and appends one event to the ledger, and a commit will carry both.
The same moves from a terminal

majordomus plan start I1502

majordomus plan verify I1502

majordomus plan done I1502

What it is

Objective
Make a running server's own root and health documents carry the identity of the code it is serving, so that a stale server is detectable by the client reading it rather than only by an outside reader holding a newer executable.
Why
F1 of the audit's failure table, and the audit names it the single most dangerous class it found, because every measurement anyone takes through such a server is quietly wrong — including measurements of what a development surface lacks. It was measured from both sides in one sitting: `serve status` in a fresh executable reported the primary checkout's server as outdated, with the reason that the executable it was started from has been replaced since, while the same server asked directly at /api/v1/server returned HTTP 200 and standing `ready`, with peers attached to it throughout. The asymmetry is structural: the lease reader in a fresh executable can tell, and the running server's own root document carries no identity to check against.
Now
Four of the five servers running during the audit were outdated. A server reports `ready` from its own endpoint regardless of whether its executable still exists on disk, and its root document carries no HEAD, no build identity and no executable fingerprint for a reader to compare. This is the ghost-server class: a server that answers is not a server that is current.
Wanted
A client that reads a server's own documents can decide whether that server is current, without holding a second executable. A stale server says so where it is asked, in the same place it says it is ready.
Done when
unknown: the record declares no `completion`
Risk
Low in mechanism, high in value. The risk worth naming is the opposite one: a check that flags a current server as stale would make every worker ignore the signal, which is worse than not having it.

Acceptance

  • A server whose executable has been replaced reports that fact on the endpoint a client asks for its standing
  • The check is answerable by a client holding no second executable
  • A current server is not reported stale, proved by a fresh start
Validation
bin/majordomus-cli serve statusbash test/run.sh
Evidence required
stale_server_says_socurrent_server_is_not_flagged
Evidence present
stale_server_says_socurrent_server_is_not_flagged

Scope

Touches
apps/majordomus-cli/src/serverapps/majordomus-cli/src/capability/builtin/server.rsapps/majordomus-cli/src/capability/builtin/health.rsdocs/COCKPIT.mdtest/cases
Not
Reaping the server register. The fleet listing enumerates every checkout it has ever seen, including long-gone scratch trees under /private/tmp, and nothing reaps it; that is a separate finding and not this issue.Killing or restarting another checkout's server. Several live sessions share this machine.
Depends on
none
Priority
p0
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-09-11
Updated
2026-10-08T10:34:20Z
Started
2026-10-08T10:33:49Z
Verified
2026-10-08T10:34:14Z
Completed
2026-10-08T10:34:20Z

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.