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

I2127

A server that lost its lease hands its sessions on and ends

Where it stands

devtask.issue

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

Moves

plan.transition

What it is

Objective: Make a server that lost or was superseded in its lease answer its existing MCP sessions with session-not-found after a bounded in-flight grace, so their bridges re-attach to the current leaseholder and the old process reaches its own end.
Why: A lost or superseded server keeps serving its existing sessions 'and ends with them' (apps/majordomus-cli/src/http/mcp.rs:113-118). Bridges ping every 20 s (apps/majordomus-cli/src/mcp/bridge.rs:19) and the serve loop counts bridged sessions as attached (apps/majordomus-cli/src/commands/serve.rs:136-146), so a server running replaced code never idles out while any bridge lives, and its clients stay on old code until they exit. docs/MCP.md:48 (the ping) and :50 (the server ends when the last peer goes) together make a superseded server immortal; :118 says only that 'the process ends with them'. Baseline audit of 2026-10-09 at master 1fb8d6be44, lifecycle gap 4 and drift 7.
Now: After a supersession, a new initialize gets 409 lease_lost (apps/majordomus-cli/src/http/mcp.rs:119-128, apps/majordomus-cli/tests/lease_lost.rs::a_server_that_lost_its_lease_says_so_and_takes_on_nobody_new), but sessions opened before it are served indefinitely.
Wanted: lease::lost records when; for the declared busy grace a superseded server answers its sessions, then closes each one on its next request with 404 session_not_found, which the bridge answers by opening a session, being refused 409 lease_lost and electing the current server; serve ends once it holds no session (superseded_and_alone). A request in flight is answered where it started. Not measured here: the full client path through a real bridge to the new leaseholder (the 404 path it relies on is the bridge's existing one, tested in mcp_shared).
Done when: unknown: the record declares no `completion`
Risk: unknown: the record declares no `risk`

Acceptance

A bridged client attached to a server whose lease is then taken over is answered by the new leaseholder within the declared grace, with no request lost
The superseded process exits by itself after its sessions moved, while the bridges are still alive
A request in flight at the moment of supersession receives its own answer, not a 404
docs/MCP.md states the grace and that a lost server ends

Validation: bin/majordomus plan validatecargo test --test lease_lost --test mcp_shared
Evidence required: lost_server_hands_sessions_on_testsuperseded_server_exits_test
Evidence present: lost_server_hands_sessions_on_testsuperseded_server_exits_test

Scope

Touches: apps/majordomus-cli/src/http/mcp.rsapps/majordomus-cli/src/shared.rsapps/majordomus-cli/src/commands/serve.rsapps/majordomus-cli/src/mcp/bridge.rsapps/majordomus-cli/tests/lease_lost.rsapps/majordomus-cli/tests/mcp_shared.rsdocs/MCP.md
Not: unknown: the record declares no `non_scope`
Depends on: none
Priority: p1
Profile: implementation
Parallel safe: false
Owner: unknown: the record declares no `owner`

The work so far

Branches: none
Merged: none
Commits: 0
Trunk: master
Sessions: none
Created: 2026-10-09
Updated: 2026-10-14T22:13:35Z
Started: 2026-10-14T22:12:56Z
Verified: 2026-10-14T22:13:14Z
Completed: 2026-10-14T22:13:35Z

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.