Data-Plane Messages Are Stream Plumbing

Five message types in MeshWeaver.Data.Contract carry data between hubs:

They are the wire format of the synchronization streams. They are not an application API. Application code — layout areas, handlers, services, Blazor views, NodeType sources — reads and writes nodes through the stream surfaces, and those surfaces use these messages underneath:

Why this matters: the second path has its own identity surface

A bespoke GetDataRequest/DataChangeRequest is a second read/write path beside the sanctioned one, and it re-implements — or forgets — everything the stream surfaces already do: whose identity the delivery carries, where it is issued from, how an absent node is answered, how a concurrent write is merged. The incident family "Portal (reads) hub posts GetDataRequest to X with no AccessContext — rejected at the identity gate" (#1253, #5431–#5439) lives entirely on that second path.

The write side shows the same thing, measured. UserActivityLayoutAreas.ClearUserBody used to read the user node once and post the whole node back as a DataChangeRequest. Run as the user bodyowner, the owner recorded the write as LastModifiedBy = "system-security" — the authorship the earlier read happened to return — and the router logged ROUTER_TRAFFIC ORIGIN: DataChangeRequest was POSTED with the mesh hub as sender. Through GetMeshNodeStream(path).Update(…) the same write is stamped bodyowner (NodeWritesGoThroughTheStreamTest, which fails on the old path with exactly that message). The stream write also applies the change to the node's current state, so a field the caller did not touch is never overwritten from a stale copy.

The target

1. Every caller outside the data layer is converted. The data layer is src/MeshWeaver.Data + src/MeshWeaver.Data.Contract — where the types are defined, registered in the type registry and served.
2. [Obsolete] on the five types once core's own callers are gone, pointing at the table above. It lands only then, because under -warnaserror every remaining reference would otherwise need a suppression.
3. internal, with InternalsVisibleTo for the data layer's own assembly (MeshWeaver.Data) and its test projects, and nothing else — when core, MeshWeaver.Plugins, every satellite and the reachable live mesh are at zero.

Before step 3, a test must show that an internal GetDataRequest/GetDataResponse still round-trips across hubs — type-registry registration by typeof (in DataExtensions) and the polymorphic $type JSON both work on non-public types — and across an Orleans grain boundary. Step 3 removes public surface, so its pull request carries Pairs-with: and the in-mesh sweep evidence below.

🚨 Why a ratchet and never a delete: in-mesh C# — NodeType Source/*.cs, scripts, cells installed from a cellSurface: true course — compiles at RUNTIME and is invisible to dotnet build and to any source scan. A type that disappears breaks those callers silently, in production (AGENTS.md: Green CI does NOT mean the mesh compiles).

The ratchet

DataPlaneMessageRatchetGuard (test/MeshWeaver.Documentation.Test) scans src/, memex/, tools/ and samples/ (whose Data/ trees are in-mesh C#), excluding the data layer, and counts code references to each of the five types (comments and strings masked). test/DataPlaneMessageSites.allow lists every file that still carries one, per type, with its count; the guard's TotalBudget caps each type's sum. A new file, a higher count, or a grown total is RED. A count that dropped is reported as STALE — lower the line and the budget in the same change.

Inventory

Counts are code references (a handler registration, a parameter type and a construction each count one). Measured on main at 39f49494eb (core) and e9d9283ab (MeshWeaver.Plugins).

Core production code — after the first conversion

PatchDataChangeRequest and DataChangedEvent are already at the target in core production code: nothing outside MeshWeaver.Data references either. They are the upstream patch and the downstream emission of SynchronizationStream, and no application C# observes them (the only C# references outside the data layer are tests — 2 and 25 in core, 0 and 4 in Plugins). But DataChangedEvent is ALSO the frame external clients decode — see below — so its wire name and fields are frozen whatever its C# visibility.

Core production code — remaining sites by kind

MeshWeaver.Plugins production code

That is 18 production references in 8 files. The rest of Plugins' references — 123 GetDataRequest, 15 GetDataResponse, 29 DataChangeRequest and 4 DataChangedEvent — are in test projects, most of them reading one node to assert on it; the recipe there is the same GetMeshNodeStream(path) wait-on-condition shown in Satellite Entity Patterns.

Outside the two src/ trees

Swept with git grep -w on each repository's origin/main, with a positive control (core src/: 523 lines) run in the same script — an empty answer from a sweep that could not have matched is not a zero.

Moving GetMeshNode onto the node stream

GetMeshNodeOutcome is the last and largest node read on GetDataRequest. Its recycling re-probe lost the read's identity until #5444; whether the wider incident family (#5431–#5439: GetDataRequests from portal/reads-* to partition roots such as Mail, Stripe, ThreeBody) goes through this method or another GetDataRequest issued on the read hub is NOT established here — those log lines name the message and target, not the calling site. Swapping its transport for IMeshNodeStreamCache is not a transport swap: the two reads decide different things, in different places.

Measured (local, Monolith, the SystemOwnedSyncConfigIsVisibleToPlatformAdminsTest fixture, reading a system-owned Space's _GitSync as the platform admin, whose fold on that path is None and whose Read comes only from GitHubSyncConfigAccessRule):

GetMeshNodeOutcome:  Present
StreamCache:         UnauthorizedAccessException: User 'platform-boss' lacks Read permission on 'Owned…/_GitSync'

So moving GetMeshNode onto the cache as it stands would DENY reads a node-type rule grants — and, for any type whose rule is narrower than the fold, ALLOW reads the owner refuses. That is a change to the authorization model of 100+ reads, not a refactor, and it needs a decision before code:

1. Reader-side rule parity. Should the cache's read gate apply the node-type rules and the Read validators the way the owner's delivery gate and validator pipeline do? That also changes what every EXISTING GetMeshNodeStream reader sees — the measurement above is a live inconsistency today, independent of GetMeshNode.
2. A delete tombstone on the subscription protocol, so the stream can say DeleteInProgress.
3. An absent-aware one-shot read on the cache (NodeReadOutcome out, no negative-cache admission for a single bounded read), so an existence probe cannot arm the storm-breaker against the create that follows it. The scope:children listing is not a substitute for GetMeshNode: its negative can be minutes old, and read-after-create callers would read their own write as absent.

Until those land, GetMeshNodeOutcome stays on GetDataRequest, which after #5444 carries the read's identity on every probe.

What changed first

A write issued from a callback — after a form stream emits, not on the click's own delivery turn — captures the caller's AccessContext on the click and runs the cold write under access.RunAs(caller, () => …): the AccessContext is an AsyncLocal, and the stream write stamps whatever is ambient when it is CALLED. Content is changed through the TYPED Update<TContent>((node, content) => …), which fails the write on present-but-unreadable content instead of defaulting it — a read-tolerant ContentAs<T>() ?? new T() inside a write destroys the record it cannot read.

Related: CQRS — Queries vs. Content Access · Data Access Patterns · The Read Path Minted a Hub Per Read · AccessContext Propagation.