fix(layout): the Catalog guard reads the registry its render uses (#5065) by rbuergi · Pull Request #5161 · Systemorph/MeshWeaver

rbuergi · 2026-09-21T22:42:32Z

Closes #5065.

The root: a guard that interrogated a different registry from the read

DomainLayoutAreas.Catalog resolved its ITypeDefinition from the hub's ITypeRegistry, then handed
it to DomainCatalogLayoutArea.RenderCatalog, which streams
Workspace.GetStream(new CollectionReference(collectionName)) — DataContext.DataSourcesByCollection.
Two different tables. The type registry is the hub's SERIALIZATION registry: DataContext.Initialize
registers every mapped type source into it, PolymorphicTypeInfoResolver adds any type the hub merely
serialises, and every content type a NodeType declares lands there. DataSourcesByCollection holds only
what a data source MAPS.

For the mapped types the two agree, which is why this passed review and every test. For Harness — a
NodeType content record with no data source — they do not, and the guard let it through to die three
frames deeper:

System.ArgumentException: Collections Harness are not mapped to any source.
   at MeshWeaver.Data.WorkspaceStreams.CreateWorkspaceStream[TReduced,TReference](…)  WorkspaceStreams.cs:38
   at MeshWeaver.Data.ReduceManager`1.ReduceStream[TReduced](…)
   at MeshWeaver.Layout.Domain.DomainCatalogLayoutArea.RenderCatalog(…)              DomainCatalogLayoutArea.cs:46

An unhandled throw out of a render reaches LayoutAreaHost's top-level Catch, which logs at Error
— the level that auto-files an incident — and renders the exception's own text. So an AUTHORING mistake
(@@Catalog/Harness naming a type that is not a workspace collection) was reported as an engineering
defect and the viewer was shown a sentence about the framework's collection map. AreaErrorClassifier
already demotes exactly this class (IsAccessDenied, IsNodeGoneNotFound → Warning + viewer copy); an
unmapped collection belongs in that company.

The fix asks the registry the read uses — area.Workspace.DataContext.GetTypeSource(collection) —
which is the same map keyed the same way (DataContext.Initialize builds TypeSources and
DataSourcesByCollection in one pass) and the set AddTypesCatalogs enumerates to OFFER catalog
links. The accept set and the offer set become one set, which is what stops the guard drifting from the
read a second time. Both of the area's declines are now localized; the missing-Id one was a hard-coded
English literal.

The control

TestCatalogOfATypeThatIsNotAWorkspaceCollection sits opposite the existing TestCatalog across
exactly one condition (DataRecord is mapped, UnmappedRecord is not; both are in the same
TypeRegistry, which is why the old guard could not tell them apart). Reverting the guard alone
reproduces the production reading in-process:

[Warning] [MeshWeaver.Data.Workspace] There were unmapped collections: UnmappedRecord
[Error]   [MeshWeaver.Layout.Composition.LayoutAreaHost] Rendering failed for area Catalog
Exception: System.ArgumentException: Collections UnmappedRecord are not mapped to any source.
   at MeshWeaver.Data.WorkspaceStreams.CreateWorkspaceStream … WorkspaceStreams.cs:line 38
viewer text: "⚠️ **This area failed to render.** ``` Collections UnmappedRecord are not mapped to any source. ```"

	control (guard reverted)	this branch
`DomainLayoutServiceTest`	total 3, failed 1, succeeded 2	total 3, failed 0, succeeded 3

The assertion is on the CONTROL TYPE, deliberately: before the fix the area still produced a control
(the host's Catch renders an error panel), so "the area produced something" proves nothing.

Two diagnostics in the same family

Both named nothing a reader could follow up, which is the reason each issue is open rather than fixed.

#4597's remaining half. ObjectAsExtensions.LogRecoveryFailure dropped the what its callers
already pass and its two sibling report sites already print, so
As<MarkdownContent> could not recover value: JsonException had no referent — not the node, not the
partition, not which of the many writers of markdown content sent it. The incident's own review recorded
that as the blocker: "LogRecoveryFailure deliberately withholds content AND carries no node path, so
there is nothing to look up." It now prints for {What}. Content and exception text stay withheld,
which is the load-bearing half of that contract; a node path is already in this file's other two log
lines and ContentAs<T> is documented as "this same conversion with the node's path in the diagnostics",
so no new class of information is exported.

🚨 And that is a finding about the test. ObjectAsPrivatePayloadTest passed the private text AS the
what argument and asserted the log did not contain it — which reads as "content is not published" and
actually measures "the caller-supplied subject is dropped". Those are different claims and only the
first is the accessor's contract. The two strings are now separate, and the test asserts both halves:
the content is absent AND the subject is present.

#5120's refusal. JsonSynchronizationStream.CreateSynchronizationStream printed
"No reducer defined for MeshNodeReference from MeshNodeReference" — the same type parameter twice
where the reduced type belonged, doubled space and all, and neither the hub that refused nor the
subscriber that asked. It now names all four. The condition is real and reachable, not impossible: a hub
configured with AddData() HAS a workspace, so Workspace.SubscribeToClient runs and reaches the
reducer lookup, but only AddMeshDataSource registers MeshNodeReference → MeshNode — so the mesh's
infrastructure hubs (portal/nodeops-{meshId}, portal/reads-{meshId}), which carry a workspace and
deliberately own no mesh node of their own, accept the subscribe and have nothing to reduce with.
Registering a reducer there would be the wrong fix (a CreateNodePermissionAttribute anchors at the
RECEIVING hub's path — that is why WithNodeOperationExecution must never land on a per-node hub), so
what the refusal has to make answerable is who asked an address with no node for its node. That is the
subscriber, and the subscriber is now in the message. #5120 stays open until the next occurrence
names its caller.

Verification

dotnet build -c Release -warnaserror — whole solution, 0 Warning(s) 0 Error(s), 66 assemblies,
MeshWeaver.Hosting.dll rewritten inside the build window (so the dependents recompiled against the
changed Data and Mesh.Contract).
DomainLayoutServiceTest 3/3 · ObjectAs* + LocalizationTest 80/80 ·
NodeUpdateContentTypeChangeTest (NodeUpdatePipeline logs "As<MarkdownContent> could not recover value" at Error for stored content with no $type (EmailContent half fixed by #4679; remainder fixed in #5926) #4597's own control suite) 6/6 ·
DocumentationLinkIntegrityTest 1/1 — which caught six bare sibling links in the new page first.
No public type or member removed, no interface member added, no behaviour change behind an unchanged
signature reaching another repo. LogRecoveryFailure is private.
Nothing to recycle: no NodeType source, no node content shipped in an image or a bake, and no layout
area compiled in the mesh is changed by this diff.

Mirror-sync: npm run sync:i18n -- --ref <merged core sha> in MeshWeaver.Plugins for the two added keys
catalog.needsType and catalog.notAWorkspaceCollection. Both are NEW keys with no value drift, so the
plugins drift guard is green either way — this is the debt-declaration, not a red.

Doc: Doc/Architecture/ThreeRegistriesAReadCanMiss, linked from the Architecture topic map.

🤖 Generated with Claude Code

) `DomainLayoutAreas.Catalog` resolved its `ITypeDefinition` from the hub's `ITypeRegistry` and then handed it to a render that streams `Workspace.GetStream(new CollectionReference(...))` — it checked one registry and read another. The two are not the same set and are not meant to be: the type registry is the hub's SERIALIZATION registry, which every content type a NodeType declares lands in, while `DataContext.DataSourcesByCollection` holds only the collections a data source MAPS. A type in the first and not the second walked past the guard and died three frames deeper as a bare `ArgumentException: Collections Harness are not mapped to any source` — an unhandled throw out of a render, so `LayoutAreaHost` logged it at Error (the level that auto-files an incident) and put that framework sentence in the viewer's face for what is an authoring mistake. The guard now asks `DataContext.GetTypeSource(collection)`, which is the same map keyed the same way AND the set `AddTypesCatalogs` enumerates to OFFER catalog links — so the accept set and the offer set are one set. Both of the area's declines are now localized (`catalog.needsType`, `catalog.notAWorkspaceCollection`); the first was a hard-coded English literal. Control: `TestCatalogOfATypeThatIsNotAWorkspaceCollection` sits opposite the existing `TestCatalog` across exactly one condition. Reverting the guard alone reproduces the production reading in-process — `There were unmapped collections: UnmappedRecord`, `Rendering failed for area Catalog` at Error, `WorkspaceStreams.cs:38` — and fails the new test; 1 failed / 2 succeeded against 3 succeeded. Two diagnostics in the same family, both of which named nothing a reader could follow up: * `ObjectAsExtensions.LogRecoveryFailure` dropped the `what` its callers already pass and its two sibling report sites already print, so `As<MarkdownContent> could not recover value: JsonException` had no referent — not the node, not the partition, not which writer sent it. That is #4597's remaining half, and its review recorded the missing subject as the blocker. Content and exception text stay withheld, which is the load-bearing part of that contract. `ObjectAsPrivatePayloadTest` passed the private text AS the subject and asserted its absence, which reads as "content is not published" but measures "the caller's subject is dropped" — the two strings are now separate and the test asserts both halves. * `JsonSynchronizationStream`'s reducer refusal printed the same type parameter twice where the reduced type belonged, and named neither the hub that refused nor the subscriber that asked (#5120). It now names all four. The condition is real and reachable: a hub with `AddData()` has a workspace and reaches the lookup, but only `AddMeshDataSource` registers `MeshNodeReference -> MeshNode`, so the mesh's infrastructure hubs — which own no node on purpose — accept the subscribe and have nothing to reduce with. Doc: `Doc/Architecture/ThreeRegistriesAReadCanMiss`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Copilot

Copilot review overview

🟢 Approval recommended

The changes consistently align guard behavior with the actual workspace registry used by the render path, add localized viewer-facing copy, and include targeted regression coverage and clearer diagnostics without introducing async/task patterns in src/.

Review effort: Lite
Findings: None

What changed in this PR

This PR fixes a production-facing failure mode in the Domain @@Catalog layout area by ensuring its precondition guard interrogates the same registry that the render path actually reads (workspace-mapped collections), preventing unmapped-but-serializable types (e.g., NodeType content records) from reaching Workspace.GetStream(CollectionReference) and throwing during render.

Changes:

Align DomainLayoutAreas.Catalog guard with the workspace DataContext collection/type-source map and return localized, actionable cautions instead of throwing for unmapped collections.
Strengthen diagnostics: include the caller-supplied subject in ObjectAsExtensions recovery-failure logs, and expand reducer-missing errors in JsonSynchronizationStream to name hub/subscriber/types/stream.
Add regression tests and an architecture doc page explaining the three distinct “not registered” registries involved in these failures.

File	Description
test/MeshWeaver.Messaging.Hub.Test/ObjectAsPrivatePayloadTest.cs	Updates test to distinguish “private content” from diagnostic subject and assert both privacy + diagnosability.
test/MeshWeaver.Layout.Test/DomainLayoutServiceTest.cs	Adds a negative control covering “type is in TypeRegistry but not a workspace collection” behavior.
src/MeshWeaver.Messaging.Hub/Localization/strings.en.json	Adds localized catalog error/help strings (English).
src/MeshWeaver.Messaging.Hub/Localization/strings.de.json	Adds localized catalog error/help strings (German).
src/MeshWeaver.Mesh.Contract/ObjectAsExtensions.cs	Ensures recovery-failure logs include the subject (`what`) while still withholding content/exception messages.
src/MeshWeaver.Layout/Domain/DomainLayoutAreas.cs	Fixes Catalog guard to use workspace `DataContext.GetTypeSource` and return localized cautions instead of throwing.
src/MeshWeaver.Documentation/Data/Architecture/ThreeRegistriesAReadCanMiss.md	Adds a new architecture page documenting the three registries and the failure modes.
src/MeshWeaver.Documentation/Data/Architecture.md	Links the new architecture page from the Architecture topic map.
src/MeshWeaver.Data/Serialization/JsonSynchronizationStream.cs	Improves “no reducer defined” refusal message to include hub/subscriber/types/stream context.
src/MeshWeaver.Compiler.Pipeline/NodeTypeCompilationHelpers.cs	Updates commentary to reflect the improved reducer-missing diagnostic wording.

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

github-actions · 2026-09-21T22:48:34Z