Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#7,136 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug sev:M

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
Fingerprint b4a0c899bb952458
Category MeshWeaver.Messaging.MessageHub
Severity Error
Top frame `MeshWeaver.Mesh.MeshNodeStreamExtensions+<>c__DisplayClass6_1.g__Issue
Namespace memex-cloud
Pods memex-portal-deployment-8b989f864-t92gc
Occurrences 1
First seen 2026-10-24 17:58:35Z
Last seen 2026-10-24 17:58:35Z
Routing not determined — no configured route matches the category MeshWeaver.Messaging.MessageHub. This repository is the configured fallback, not a finding about who owns the fault; the category names the LOGGER, which may not be the subject.
Recent log lines 
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.

Lingua principale
C#
Stelle
12
Fork
5
Merge medio
6h 37m
PR unite (30g)
913

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Systemorph/MeshWeaver

Tutte le issue di Systemorph/MeshWeaver

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.