MeshNodeStreamExtensions.GetMeshNodeOutcome posts a one-shot GetDataRequest node read with the router as sender

Start with MeshNodeStreamExtensions.cs:3849 and the b__0 lambda at :4039 inside GetMeshNodeOutcome — determine which hub the Rx Observable.Create posts its GetDataRequest from, and whether a seam like MeshExtensions.ReadIssuingHub() exists but is bypassed. Read Doc/Architecture/RouterTrafficDetection (section on request/response READs) and the related issues #4616/#5937 for the same failure shape. Reproducing the log context for delivery 79f720d5ccdb7424 may identify the driver. Done: the read is posted from a node-scoped hub (e.g. ReadIssuingHub()) with an owning node as target, and the ROUTER_TRAFFIC ORIGIN detector no longer fires for this call site.

Observed

The ROUTER_TRAFFIC ORIGIN detector (per Doc/Architecture/RouterTrafficDetection) caught a one-shot node READ leaving the router: a GetDataRequest was posted with the mesh hub — mesh/YYNcCvav1EGiqF7wIvsF_Q, the ROUTER — as sender, addressed at the node rbuergi/MeshWeaverInstance/pearl. The role is sender, i.e. the post left the router and the posting call site is the one that chose it. The origin line names the call site: MeshWeaver.Mesh.MeshNodeStreamExtensions+<>c__DisplayClass6_1.<GetMeshNodeOutcome>g__Issue|5 (MeshNodeStreamExtensions.cs:3849), invoked from <GetMeshNodeOutcome>b__0 (MeshNodeStreamExtensions.cs:4039) inside an Rx Observable.Create subscription (SubscribeCore/ObservableBase.Subscribe frames).

GetMeshNodeOutcome is a request/response read of exactly the class the architecture doc's section "A request/response READ neither ratchet can see" describes: GetDataRequest is neither a node-lifecycle message nor posted on a field the code has declared router-capable, so both src/ ratchet guards are blind to it by construction and the runtime ORIGIN line is the only instrument that names it. The sample's stack is truncated below the Rx plumbing, so the code that drove GetMeshNodeOutcome from the root hub is not visible in this evidence.

Where and when

Single occurrence, single pod (memex-portal-deployment-8b989f864-t92gc, namespace memex-cloud), at 2026-10-24 17:58:35Z. Note the origin site dedups once per (role, message type) per hub lifetime, so occurrences: 1 means one report per process lifetime — the violating path may have run more than once. The incident carries one correlated delivery id, 79f720d5ccdb7424.

Impact

No user-visible failure is in evidence — the detector never blocks, and a read posted from the router still delivers. The risk is the documented wedge class (prod 2026-06-11): work on the router's action block competes with routing, and a burst of such reads starves real SubscribeRequest traffic. At this volume it is a hygiene violation on a secondary path, not an outage.

Not established

• The cause: the evidence does not show which code drove GetMeshNodeOutcome on the root hub — the stack below the Rx plumbing is truncated in the sample.
• Whether it recurs or fires on other pods: one report on one pod is all the incident carries; the per-hub dedup hides recurrence on the same pod.
• Whether the read itself succeeded or failed — the detector reports the addressing violation, not the delivery outcome.
• Whether GetMeshNodeOutcome uses a seam conditionally with a bare fallback branch (the #5937 shape) or posts straight off the injected hub — not readable from this evidence.

Candidate causes and the reading that separates them

1. A mesh-singleton or hosted service resolved from the root container drove the read. Its DI-injected IMessageHub is the router, so a GetMeshNodeOutcome issued through it posts as mesh/{id}. Predicts: the report recurs once per pod lifetime wherever that service runs, across pods, and the target path varies with what the service reads. Separating reading: the frames below the Rx plumbing in a fuller stack capture, or the log context around delivery 79f720d5ccdb7424, name the driving service.
2. A conditional seam with a bare self-directed branch (the MeshOperations.TryResolveUnifiedPath #5937 shape): GetMeshNodeOutcome hops the read onto a seam except when target resolves to its own hub, and the bare branch posts from the router. Predicts: the report only appears for targets that resolve to the posting hub's own address, and never on a per-node/session caller. Separating reading: the target here (rbuergi/MeshWeaverInstance/pearl) does not look like the posting hub's own address, which leans against this cause but does not exclude a resolution fallback (cf. #5937's address-less unified path defaulting to hub.Address); reading GetMeshNodeOutcome's hub selection settles it.
3. A one-off invocation from a root-hub tool/agent surface. Predicts: no recurrence. Separating reading: the same fingerprint appearing on other pods or in later windows rules it out.

Where to look

• MeshWeaver.Mesh.MeshNodeStreamExtensions.GetMeshNodeOutcome (MeshNodeStreamExtensions.cs:3849 and the b__0 lambda at :4039) — which hub the Observe posts from, and what the callers pass.
• Doc/Architecture/RouterTrafficDetection — section "A request/response READ neither ratchet can see" covers this exact class and why neither src/ ratchet sees it.
• Related, same detector family but different call sites (not duplicates of this ticket): #4616 (MeshOperations.TryResolveUnifiedPath), #5726 (ContentIndexingObserver.RegisterCollection), #5937 (address-less unified path defaulting the target to the router), #5900 (chat autocomplete). No prior incident names GetMeshNodeOutcome — this is a first report at this call site.

Evidence

2026-10-24 17:58:35Z memex-portal-deployment-8b989f864-t92gc fail: MeshWeaver.Messaging.MessageHub[0]
      ROUTER_TRAFFIC ORIGIN: GetDataRequest was POSTED with the mesh hub as sender (sender: mesh/YYNcCvav1EGiqF7wIvsF_Q, target: rbuergi/MeshWeaverInstance/pearl). The mesh hub is the ROUTER and must not be an end of a work delivery. If the role above includes 'sender', this post LEFT the router: hop it onto the seam that matches what this delivery IS — MeshExtensions.NodeOperationIssuingHub() for a node LIFECYCLE write, MeshExtensions.ReadIssuingHub() for a bounded one-shot READ, MeshExtensions.StreamSubscribingHub() for a remote stream SUBSCRIPTION. The three are NOT interchangeable and the wrong one fails SILENTLY: ReadIssuingHub() registers no handlers by design, so a subscription hopped onto it stops reporting AND stops receiving data (#4614). If the role above includes 'target', ask where that target CAME FROM, because the two cases have opposite fixes: if this call site CHOSE the router as the destination, the call site is the offender — address the owning node instead (MeshExtensions.NodeOperationTarget()); if the target was read off an incoming request or subscription (request.Subscriber, ResponseFor(delivery) — SubscribeAck, DataChangedEvent, StreamErrorEvent and StreamEndedEvent all are), then this call site is the innocent answering half and the hub to move is the one that SUBSCRIBED or REQUESTED (#4697). 'sender AND target' means both apply. Reported once per role+type for this hub. Call site:
         at MeshWeaver.Mesh.MeshNodeStreamExtensions+<>c__DisplayClass6_1.<GetMeshNodeOutcome>g__Issue|5 (MeshNodeStreamExtensions.cs:3849)
         at MeshWeaver.Mesh.MeshNodeStreamExtensions+<>c__DisplayClass6_0.<GetMeshNodeOutcome>b__0 (MeshNodeStreamExtensions.cs:4039)
         at System.Reactive.Linq.QueryLanguage+CreateWithDisposableObservable`1.SubscribeCore
         at System.Reactive.ObservableBase`1.Subscribe
         at System.Reactive.Linq.ObservableImpl.Select`2+Selector.Run
         at System.Reactive.Producer…[truncated]

_{Opened automatically from Admin/_LogIncident/b4a0c899bb952458. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 039dbd9efb673155: other fingerprints of this site fold in here as comments rather than opening tickets of their own.}