GitSync: a partial import records the content fingerprint anyway, so five Hosting NodeTypes are parked on a source node the import dropped and re-import is skipped

[rbuergi]

Measured on memex.systemorph.com, 2026-09-15 20:30–20:40Z.

A Hosting GitSync import dropped exactly one source node, reported ImportedWithContentErrors, and then recorded the content fingerprint anyway. Five NodeTypes are parked as a result, and no further import can repair it: the next update is skipped as already-imported.

The missing node. Hosting/Deployment/Source/SelfUpdateRouting exists in no partition on memex (search partitions:all name:*SelfUpdateRouting* → 0). The repository has 14 files under Hosting/Deployment/Source/; memex holds 13 nodes. The only absentee is SelfUpdateRouting.cs, added to Plugins main at 11:22Z (36ee62f3d) and carrying the same // <meshweaver> header as its siblings.

What that breaks. PlatformBuildInboxWatcher, which calls it, DID import, at 19:01Z. So five NodeTypes fail to compile, each on the symbol that is missing:

CS0246: The type or namespace name 'SelfUpdateRouting' could not be found
CS0103: The name 'SelfUpdateRouting' does not exist in the current context

Parked: Hosting/Backup, Hosting/Deployment, Hosting/InstanceAction, Hosting/InstanceRequest, Hosting/PlatformBuildInbox. No instance action can run on memex while Hosting/InstanceAction is parked — that is Sample, Logs, HelmRelease and every provisioning action on the control instance.

Why it cannot heal. Hosting/_GitSync still reports lastSyncedAt 2026-09-14T22:18Z and lastSyncCommitSha c7f03952: the outcome is not a success, so the recorded commit never advances and each attempt re-imports the same delta and fails the same way. A second update at 20:37Z answered:

Imported Skipped — an earlier FULL import already recorded this exact content at
fingerprint bb9801101e859a21 (Hosting/_Activity/import-bb9801101e859a21), so the
partition was not re-read.

So the fingerprint marker claims completeness for an import that lost a node, and the operator's one repair (re-import) is refused.

The defects, separable.

1. An import that could not write every node records a content fingerprint that says it did. A partial import must not mark the content complete.
2. ImportedWithContentErrors names a count (9), never the paths. The nodes that failed should be named, or nobody can tell what is missing.
3. A NodeType parked on a symbol whose source the import dropped cannot be repaired by Compile: the source is not there to compile.

How to reproduce the state. get @Hosting/_GitSync, get @Hosting/_Activity/6ac3721c (the 20:31Z import at Plugins 04a14676), and get_diagnostics @Hosting/InstanceAction.

Found while carrying MeshWeaver.Plugins#1935 to memex; the park predates that merge.

[rbuergi]

A forced full re-read does not repair it — the importer drops that one file consistently.

git_hub_sync(space: Hosting, op: update, force: true) at 20:39:22Z (activity Hosting/_Activity/b32f51dc) did a full read rather than the fingerprint skip, and concluded:

Pruned 2 node(s) absent from the repo: Hosting/Triage/Status, Hosting/Triage/ci-failure/…-35015210158
Imported ImportedWithContentErrors (0 node(s)).

Hosting/Deployment/Source/SelfUpdateRouting is still absent everywhere (search partitions:all name:*SelfUpdateRouting* → 0), and the five NodeTypes stay parked on CS0246 SelfUpdateRouting.

So the marker-skip is the second problem, not the first. The first is that this file never imports: a full, forced read of the branch HEAD writes zero nodes and reports content errors with a count of 0 and no paths. SelfUpdateRouting.cs is 852 lines with the same // <meshweaver> header as its 13 siblings in the same folder, all of which imported.

Worth checking: a size or shape limit in the Code-node import, and whether a previously deleted node at that path blocks recreation. Either way the operator is left with no way to fix it from the mesh: re-import is skipped, forced re-import writes nothing, and Compile cannot compile a source that is not there.

[rbuergi]

The source-side half is fixed: Systemorph/MeshWeaver.Plugins#1955.

The dropped file's cause is named in #4458 and confirmed: Hosting/Deployment/Source/SelfUpdateRouting.cs carried a literal 0x00 at line 522 / byte 30818 — string.Join('<NUL>', parts) where '\0' was meant. PostgreSQL cannot store a NUL in text, which is precisely why the import could drop that one file while every sibling under Hosting/Deployment/Source/ landed. #1955 replaces it with the escape (same character, storable) and adds a guard refusing a raw NUL in any file the installer maps to a node.

That does not close this issue, and this issue is the half that matters more. The repository being correct changes nothing on its own: Hosting/_GitSync has already recorded the content fingerprint for a commit whose import was partial, so the corrected file is skipped as already-imported. The defect this issue names — a partial import records the fingerprint anyway — is what makes the damage permanent, and it would do the same for the next unstorable node, whatever the reason.

Two things worth stating for whoever takes it:

1. The blast radius is the control instance's action surface. With Hosting/InstanceAction parked there is no Sample, no Logs, no HelmRelease and no Roll — which is why memex-cloud is still serving core c84c6c05 (2026-09-12) and why the fixes waiting on a Roll (DynamicTypePreWarmer readiness gate stalls rollout when upstream NodeType Store/Coupon fails #1130, Agent skill-discovery search issues unanchored nodeType:Skill query — fan-out UNION over every partition schema #4443, Unanchored nodeType:*Post wildcard query UNIONs every partition schema — name and anchor the census's wildcard caller (#4) #3545, Plugins#1823) could not have been delivered no matter how many times one was attempted.
2. ImportedWithContentErrors should not be a fingerprint-recording outcome. That is the one-line statement of this defect, and it is also the difference between a self-healing miss and a permanent one.

_{Measured 2026-09-15 by Claude Opus 5.}

[rbuergi]

Correcting myself: I overstated the permanence a comment ago, and the difference decides whether recovery needs a core change first.

I wrote that "the repository being correct changes nothing on its own … the corrected file is skipped as already-imported." That is too strong.

The skip is keyed to a commit — Hosting/_GitSync carries lastSyncCommitSha c7f03952. Plugins#1955 lands a new commit touching that very file, so the next sync is not the already-imported case at all: it has a sha it has never seen. And the reason a forced full re-read did not repair it — "the importer drops that one file consistently", your 20:41Z measurement — is the NUL itself, which is exactly what #1955 removes.

So the expected sequence once #1955 merges and Hosting syncs is: new sha → import runs → the file is now storable → Hosting/Deployment/Source/SelfUpdateRouting lands → the five parked NodeTypes recompile → Hosting/InstanceAction unparks → instance actions (and therefore the Roll) work again. No core change required to recover.

What that does not do is fix this issue. The defect stands exactly as titled: a partial import recording the fingerprint anyway is what turned a single unstorable file into a state no re-import could repair, and it would do the same for the next one — a file too large, a permission fault mid-import, any content the store refuses. The recovery here happens to come for free only because the repair edits the offending file, which mints a new commit. A dropped node whose file does not need editing would still be permanent.

One line is the whole fix surface: ImportedWithContentErrors must not be a fingerprint-recording outcome.

I have no mesh read to confirm the sequence above — the memex MCP token expired mid-session — so treat it as the expected behaviour from the recorded shas rather than as a measurement.

_{Corrected 2026-09-15 by Claude Opus 5.}