A dispatch HOLD must name a human owner and an expiry — and must not be ambient state

[thegeorgepu]

A control file that halts other sessions' work froze a worker queue for hours today. Nobody could say who placed it or why, and the justification named an authority that does not exist.

What happened

scratchpad/endurance/HOLD, written 2026-08-29T23:53:46Z:

hold requested 2026-08-29T23:53:46Z
reason: Mission Alpha queue governor: freeze dispatch while authoritative
        inventory and admission policy are established

A matching GLOBAL_HOLD_PATH check was added to may_dispatch() in endurance.py.

Consequences, all real:

• A worker session stopped dispatching and waited, with two finished task types queued behind it.
• It attributed the hold to a peer session, which had never touched the harness — so it waited on someone who could not have lifted it and did not know it was blocked.
• "Mission Alpha" appears nowhere else on disk. Grepping the entire scratchpad returns exactly one hit: the HOLD file itself. There is no plan, no inventory doc, no admission policy.
• Asked directly, the person it would have to have come from did not recognise the name.

The freeze may well have had a real technical concern behind it. That is not the problem. The problem is that nothing in the mechanism required it to be attributable, so a legitimate concern and an invented one are indistinguishable from the outside — and the only safe reading of an unattributable freeze is to honour it, which is what happened, for hours.

Ask 1 — a hold must name a person and an expiry

Make may_dispatch() refuse a hold that does not carry:

• owner: — a human, not a codename. "Mission Alpha queue governor" must not satisfy this.
• reason: — what would have to become true for it to lift.
• expires: — a timestamp. An expired hold is ignored and logged, so a forgotten one self-clears.

A hold missing any of these should be logged loudly and NOT honoured. That inverts the current failure mode: today an unattributable hold silently stops everything, when it is precisely the one that has earned the least deference.

Ask 2 — the hold path is ambient state, and it breaks the test suite

may_dispatch() reads GLOBAL_HOLD_PATH = os.path.join(HERE, "HOLD") — filesystem state next to the module. The harness's own unit tests construct a Dispatcher and call tick(), so with any hold present every one of them dispatches nothing.

Measured:

python3 -B -m pytest -q tests/   ->  14 failed, 8 passed
d.may_dispatch()                 ->  'controller-wide HOLD file present'
# same fixture, GLOBAL_HOLD_PATH redirected to a nonexistent path:
d2.tick(); len(d2.state["tasks"])  ->  1

Bisected: green with the hold feature reverted, green with the feature and no hold present, red only when a hold exists. The failures surface as StopIteration deep in unrelated stop-rule tests rather than "dispatch is held", so the suite lies about what is wrong.

Fix: make the hold path an explicit constructor argument the Dispatcher takes, so tests pass a temp dir. Relocating the default is not enough — the point is that a test's result must not depend on ambient state no test set.

Credit for the measurement and bisection to the session that found it while blocked.

[thegeorgepu]

Forensics: the authorship is not merely unattributed, it is unrecoverable

Ownership of the HOLD was eventually established — it sat in the blocked session's own scratchpad (ac1b0351-…), confirmed by that session. So the session that stopped work said, truthfully, "I have not touched either", while its own session directory held both the HOLD and the modified may_dispatch(). A subagent's write is invisible to its parent's self-report.

But tracing who wrote it failed, and that is the part that matters for this issue.

What was searched, and found nothing:

scope	result
all 49 project dirs on the machine	"Mission Alpha" in 2 transcripts only
those 2	the blocked session at 23:55:57Z, and a second session at 23:56:49Z
the HOLD file's mtime	23:53:46Z
180 subagent transcripts in the owning session	0 mentions
the one subagent live near that window (a814ad50…)	ended 23:48:54Z, ~5 min before the write, zero markers
task symlinks	747, 0 dangling

The earliest mention anywhere is the owning session running cat on the file — the moment of discovery, not of authorship. The phrase "queue governor" does appear in one of its subagents from six hours earlier (a2552b65…, 15:50–17:36Z), which is presumably where the vocabulary came from, but that transcript contains no HOLD markers at all.

So: a control file that froze a worker queue was written by something that left no trace in any surviving transcript on this machine. The owning session believes a concurrent subagent wrote it and that the relevant task output was later cleaned up. That is consistent with the evidence and cannot be confirmed from what remains.

Why this strengthens the ask rather than resolving it

The original framing was "a hold should name a person so you can go ask them." This is worse than that: by the time anyone thought to ask, there was no longer anything to ask. Attribution recoverable only from a transcript is attribution with a retention policy attached.

That makes the owner: field load-bearing in a way a convention cannot replace — the file must carry its own provenance, because the surrounding evidence does not survive. Same for expires:: a hold whose author cannot be identified at all has no mechanism to end other than expiry.

Concretely, the hold here lasted from 23:53:46Z until a human lifted it — through several hours of a frozen queue with finished work behind it — and at no point in that window could anyone have determined who to ask.

[thegeorgepu]

Ask 2 is already fixed — do not redo it

Verified against the live harness:

• Dispatcher.__init__ already takes hold_path=GLOBAL_HOLD_PATH and stores it as self.hold_path.
• may_dispatch() reads self.hold_path, not the module global.
• The test suite has exactly one Dispatcher construction — the make() helper — and it passes hold_path=os.path.join(out, "HOLD"), a per-test temp dir.

So the ambient-state coupling is gone and the suite no longer inherits a hold that happens to be on disk. The original report was accurate when written; it was fixed shortly afterwards. Ask 2 is closed.

The module-level GLOBAL_HOLD_PATH still exists and is still used by the hold CLI command and the pre-run check. That is correct — those are operator entry points where an ambient default is the intended behaviour.

Ask 1 is the whole remaining scope

Requiring owner: / reason: / expires: before a hold is honoured. The forensics comment above is the argument for it: authorship here was not merely unrecorded, it was unrecoverable — nothing on the machine names the author, and by the time anyone thought to ask there was nothing to ask.

Proposed rule, and the one line that matters: a hold that cannot be validated is not honoured. Uniformly — missing field, unparseable expiry, expired, or unreadable file. All ignore-and-log-loudly.

That inverts today's failure mode, where the least accountable hold got the most deference because nobody could evaluate it well enough to lift it.

Two details worth fixing in the same change:

1. The hold CLI command must require the three fields, so an invalid hold cannot be created in the first place. Validation only at the read site means a malformed hold is written successfully, silently ignored, and its author believes work is frozen when it is not — which is a worse failure than today's.
2. expires needs a ceiling. An unbounded expiry recreates the original problem with extra steps.

Note on where this code lives

endurance.py (47KB) exists only in a session scratchpad under /private/tmp, which clears on reboot. It has no repo home — vinci-gpu-research holds its records under roadmap/records/worker-endurance/, but not the harness.

So this fix cannot be made durable until the harness is upstreamed somewhere. That is arguably the larger issue: the tool that runs worker endurance testing, and the guard being added to it, both live somewhere a reboot deletes.