A static node must not shadow a durable row at the same path — make the collision loud instead of a 30s install hang #1209

What happened

Diagnosed 2026-08-11 while investigating a deterministic install: TimeoutException on the Agent and Skill plugin packages (plugins gate, platform image from core 22e4a0c9a).

A host that calls bare .AddAI() (no serveFromPartition) registers BuiltInAgentProvider/BuiltInSkillProvider as static node providers serving paths Agent and Skill. If that same mesh then installs the durable Agent/Skill plugin packages — which write real rows at exactly those paths — the two collide:

1. the durable root create is refused NodeAlreadyExists → applied as an update, activating the hub on the STATIC node;
2. MeshDataSource.WithMeshNodes() takes its static branch (FindServedStaticNode) and seeds the per-node hub with AgentNodeType.CreateMeshNode() — NodeType null, no persistence backing;
3. the hub emits one Full snapshot at v0 and never again, so anything waiting on the node's stream (here PackageInstaller.RootRetypeReconciled, PackageInstaller.cs:1762-1775) waits out its 30 s timeout.

Core already KNOWS this hazard and documents it in two places — src/MeshWeaver.AI/AgentNodeType.cs ("the static type-def and the durable row BOTH claim @agent, and the static one wins the serve seams … the per-node hub is seeded from a node that is by design NEVER PERSISTED", #902) and src/MeshWeaver.AI/AiContentSources.cs ("Drop Agent and the in-memory provider comes back and SHADOWS the DB nodes the Agent plugin installs"). The cure is per-host configuration (serveFromPartition), which the portal gets right via Helm and which the gate harness did not.

NodeTypeRebindWatcher (added in 72df41936) did not cause this — it stopped masking it: it recycles the hub on a NodeType change, and for Agent it fires twice, the second landing inside the final retype's write window.

Why a config-only cure is not enough

The failure mode is silent and total: the partition root becomes unreadable / un-creatable / un-writable, surfacing only as a 30-second timeout somewhere downstream, with nothing naming the collision. Every host must get serveFromPartition right, forever, with no diagnostic if it doesn't. Known bare-.AddAI() callers today include memex/Memex.Client/MauiProgram.cs:108 and any monolith/deployment whose Features:StaticRepoSync:Partitions is empty (the default — only Helm sets the list).

Proposal

Make the collision loud and early rather than a downstream hang. Options, roughly in order of preference:

1. MeshDataSource.WithMeshNodes refuses to serve a static node at a path that has a durable row (durable wins), and logs it at Warning naming both claimants.
2. A startup assertion: a registered IStaticNodeProvider path that also resolves to a persisted partition root fails fast with a message naming the serveFromPartition fix.
3. At minimum, PackageInstaller's post-install stream waits should name the suspected cause on timeout ("path X is served by a static provider — its hub is not persistence-backed") instead of a bare TimeoutException.

Immediate follow-up (separate, already in flight): the gate harness's own .AddAI() call is fixed so the plugins gate stops failing on Agent/Skill.

Diagnosis evidence: control run against the previous image digest passes; renaming the module root Agent→Agentz (identical content) passes; fixing the harness's AddAI makes all 20 modules pass.

🤖 Generated with Claude Code