Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#7,136 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #7230 de @rbuergi — fusionado

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
csharp
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
12
Forks
5
Merge medio
6 h 30 min
PR fusionados (30 d)
960

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Systemorph/MeshWeaver

Todos los issues de Systemorph/MeshWeaver

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.