NodeType compile stamps DispatchedBuildInputs through 1 of 11 Pending doors and never clears it on Ok — six kickoff paths can never absorb a release request (#2544), and the stamp lies after completion #3390

Activity

1. rbuergi commented on Sep 6, 2026

   

   rbuergi

   on Sep 6, 2026

   ContributorAuthor

   More actions

   Half done on main (#3405) — the terminal-clear half. The stamping half stays open.

   Verified on origin/main rather than on the PR's word — all five terminal writes now clear the
   stamp, and the guard shipped:

   NodeTypeCompilationHelpers.cs   6 × "DispatchedBuildInputs = null"   (4 pre-existing Pending doors + 2 terminal)
   NodeTypeContractHandler.cs      2 ×                                  (both terminal)
   PrebuiltAssemblySeeder.cs       1 ×                                  (terminal)
   test/MeshWeaver.Compiler.Pipeline.Test/DispatchedBuildInputsInvariantGuard.cs   present
   

   So your second bullet — "every terminal write clears the stamp, so a non-null value means in flight
   and nothing else" — holds now, and DispatchedBuildInputsInvariantGuard keeps it holding: it fails
   if a terminal CompilationStatus write does not mention the field, with a floor on the sites found
   and a self-test of the brace-balanced matcher. Confirmed it can fail by removing one clear
   (PrebuiltAssemblySeeder.cs:483) and watching it redden while the self-test stayed green.

   🚨 What is deliberately NOT done: the six unstamped Pending doors

   Your first bullet is untouched, and I want to be explicit about why rather than leave it looking
   overlooked.

   A wrong stamp is worse than no stamp. An unstamped in-flight compile parks the release request —
   the documented safe behaviour, "absorbing against an unknown input set is a guess". An
   incorrectly stamped one gets the request absorbed against a compile that will not produce
   what was asked, and nothing downstream re-checks. So the six doors are not a mechanical edit: each
   needs a judgement about what its inputs genuinely are at that point, and getting one wrong converts
   a safe park into a silent wrong answer.

   Your fix shape says the doors "all have def.CurrentSourceVersions and the guards' ModulesHash in
   reach" — that is the right starting point, and it is exactly the claim that wants checking per door
   rather than assuming across six.

   Whoever takes it now has the guard in place. Worth extending it in the same change to assert the
   other direction — a Pending flip either stamps or writes an explicit null, never leaves the
   field untouched — which is the invariant that stops door number twelve from repeating this.

   Third bullet, partially

   Your proposed test walks each door and asserts
   non-null ⇔ Pending/Compiling and the token matches. What shipped is the writing half of that,
   enforced statically. The matching half — that a stamped token actually describes the inputs
   dispatched for — still needs the runtime test you describe, and that belongs with the stamping work.

   🤖 Filed from Claude Code.
2. rbuergi commented on Sep 6, 2026

   

   rbuergi

   on Sep 6, 2026

   ContributorAuthor

   More actions

   The stamping half is in #3415 — and the count is 12 doors, not 11

   Re-measured on origin/main 4248aba7b (i.e. with #3405's terminal-clear half already in):
   12 sites flip CompilationStatus to Pending; 1 stamped; 4 wrote an honest explicit null; 7
   did not mention the field at all.

   The table above misses one — NodeTypeCompilationHelpers.cs:1532-1541, the sources watcher's
   parked auto-retry. It is the most interesting of the twelve, because it publishes a NEW source
   snapshot in the same write, so stamping def.CurrentSourceVersions there would record the broken
   set the dispatch is replacing. It needs the snapshot passed explicitly. Its sibling branch — the
   one that finds the type already Pending/Compiling and only refreshes the snapshot — must
   leave the stamp alone, because that compile really was dispatched for the old sources and a
   request formed under the new ones must still park.

   MeshOperations.cs:4368 is in the neighbourhood but is a read (a display fallback), not a door.

   Structural, per the fix shape

   NodeTypeCompilationHelpers.DispatchPending(def, modulesHash | hub) flips the status and writes
   the token, and it is now the only CompilationStatus = …Pending write anywhere in src/.
   DispatchedBuildInputsInvariantGuard asserts exactly that, and it is rewritten as a classifier
   over the assigned expression rather than a substring search for a spelling.

   That rewrite found two terminal-clear sites #3405 could not see

   Both spell the status as something other than the literal its matcher looked for, so both kept the
   stamp across a terminal write:

   • NodeTypeCompilationHelpers.ApplyCompileFailure — a ternary, Unavailable / Error
   • NodeTypeContractHandler:258 — the Unavailable marker write

   Your second bullet therefore holds now in a way it did not on main an hour ago.

   Third bullet, the runtime half

   DispatchedBuildInputsStampedAtEveryDoorTest composes each door's transition with
   IsSatisfiedByInFlightCompile — the same question the release watcher asks — so it fails if a door
   stops stamping and if the stamp is wrong. Reverting the door reddens 6; reopening one door
   reddens the structural guard, naming the site. Both counts and both failure texts are in the PR.

   What I did not do

   Not weakened the absorb predicate — a request against moved sources, a moved framework or a moved
   module set still parks, and force still always compiles. Not #3395; but it is the argument for
   accurate stamping: an accurate mod= makes a mid-boot module-set change visible to the absorb read,
   where an absent stamp merely hid it behind a park that happened to be right.

   One thing flagged rather than fixed: a Pending flip the compile watcher refuses to dispatch
   (the parked short-circuit) is briefly stamped before ApplyGateSettle clears it, so a request
   landing in that window can be absorbed against a compile that never runs. That window is
   pre-existing on the release-watcher door and unchanged in shape; closing it means teaching the
   absorb read about the park registry, which is #2544's business.

   Written up in Doc/Architecture/NodeTypeCompilation — the absorb mechanism was previously
   undocumented there.

   🤖 Filed from Claude Code.
3. rbuergi

   added a commit that references this issue on Sep 6, 2026

   test(#3390): the guard fails closed on an expression it cannot read

   ...

   f046e2a
4. rbuergi

   closed this as completedin #3415on Sep 6, 2026