fix(#1462): a stranded `Compiling` claim is re-driven by the sweep that already runs by rbuergi · Pull Request #1593 · Systemorph/MeshWeaver

rbuergi · 2026-08-14T15:59:10Z

Compiling is a non-terminal state that nothing reconciles. The flip to it is durable; the terminal write is not guaranteed — a process death mid-compile leaves the row there for good.

DynamicTypePreWarmer's "don't clobber an in-flight compile someone else already started" guard then declines to touch it on every subsequent sweep:

if (def.CompilationStatus is CompilationStatus.Pending or CompilationStatus.Compiling)
    return node;   // ← forever, for a claim whose owner died

So the type never reaches a terminal state. It is neither Ok (usable) nor Error (classifiable by #1396's discriminator), it holds portal readiness, and it parks every instance hub for the full activation budget. The row that revealed this sat at Compiling for ten weeks — harmless only because it was an orphan the prewarmer never enumerates. Apply the same mechanism to a row that is in the bake set and it is the readiness-refusal shape #1391 opened with.

The fix

The guard now defers only to a claim that can still be in flight:

state	verdict	why
`Pending`	honoured	it is what this prewarmer itself writes to ask for a compile — re-driving it would fight our own request
`Compiling`, started within the per-type budget	honoured	it can still be in flight; clobbering restarts work that is about to finish
`Compiling`, started longer ago than the budget	stranded	no driver is still working on it — it either finished (and would have written a terminal state) or it died
`Compiling`, no start timestamp	stranded	a live compile always stamps one, so this is the shape a row left over from an older write carries — and honouring it forever is how this became permanent

The bound is the sweep's own per-type budget, not a new number.

🚨 What this is not

No timer, no poller, no background sweep for stale rows. The issue rules those out explicitly ("Do not add a timer that polls for stale Compiling rows and flips them — that is the watchdog-shaped band-aid AGENTS.md rules out"), and so does AGENTS.md.

The recovery rides the enumeration that already runs, and only ever reinterprets a claim that has provably expired. StrandedCompileClaimTest pins exactly that distinction — including the case that must NOT change (a compile 5 s old is still honoured), because a fix here that clobbered live compiles would be worse than the bug.

Verification

MeshWeaver.Hosting.Test — 176/176, 8 of them new.
-c Release -warnaserror — MeshWeaver.Hosting, MeshWeaver.Hosting.Test: 0 errors, 0 warnings.

No What's New entry: the user-visible effect (a portal that will not become ready) is a failure that this prevents rather than a change they can notice.

Fixes #1462

🤖 Generated with Claude Code

https://claude.ai/code/session_01KmBFaHTqhy7h742wkAaJKj

… already runs `Compiling` is a non-terminal state and nothing reconciles it. The flip to `Compiling` is DURABLE; the terminal write is not guaranteed — a process death mid-compile leaves the row there for good. DynamicTypePreWarmer's "don't clobber an in-flight compile someone else already started" guard then declines to touch it on EVERY subsequent sweep, so the type never reaches a terminal state. It is neither Ok (usable) nor Error (classifiable by #1396's discriminator), it holds portal readiness, and it parks every instance hub for the full activation budget. One row on public.mesh_nodes sat at `Compiling` for ten weeks this way — harmless only because it was an orphan the prewarmer never enumerates. Apply the same mechanism to a row that IS in the bake set and it is the readiness-refusal shape #1391 opened with. The guard now defers only to a claim that can still be in flight: * Pending — always honoured. It is the state this prewarmer itself writes to ASK for a compile; re-driving it would fight our own request. * Compiling — honoured only while LastCompileStartedAt is within the per-type budget, the same bound the sweep gives a type to settle. Past it no driver is still working on it: it either finished (and would have written a terminal state) or it died. * Compiling with NO start timestamp — stranded. A live compile always stamps one, so an unstamped Compiling is exactly the shape a row left over from an older write carries, and honouring it forever is how this became permanent. 🚨 What this is NOT: no timer, no poller, no background sweep for stale rows — the issue rules those out explicitly and so does AGENTS.md. The recovery rides the enumeration that ALREADY runs, and only ever reinterprets a claim that has provably expired. StrandedCompileClaimTest pins that distinction, which is the whole substance of the change. Verified: MeshWeaver.Hosting.Test 176/176 (8 new); MeshWeaver.Hosting and MeshWeaver.Hosting.Test build -c Release -warnaserror with 0 errors, 0 warnings. Fixes #1462 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KmBFaHTqhy7h742wkAaJKj

Copilot

Pull request overview

This PR addresses issue #1462 where a NodeType can remain stuck in the non-terminal Compiling state indefinitely (e.g., after a mid-compile process crash), causing subsequent prewarm sweeps to permanently defer and never re-drive the type to a terminal status.

Changes:

Refines DynamicTypePreWarmer’s “don’t clobber an in-flight compile” guard to only defer to compile claims that can still be live (fresh Compiling within the existing per-type budget, or Pending).
Introduces IsLiveCompileClaim(...) to centralize and test the stranded-claim interpretation.
Adds StrandedCompileClaimTest to pin the intended behavior for fresh vs. stale/unstamped Compiling claims.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/MeshWeaver.Hosting/DynamicTypePreWarmer.cs	Updates the sweep’s guard to re-drive stranded `Compiling` claims via `IsLiveCompileClaim`, preventing permanent non-terminal status.
test/MeshWeaver.Hosting.Test/StrandedCompileClaimTest.cs	Adds unit coverage for the new “live vs stranded compile claim” logic.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

github-actions · 2026-08-14T16:14:55Z