Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MeshOperations.TryResolveUnifiedPath runs its one-shot UCR read on the router — GetDataRequest posted from and addressed at the mesh hub

Open
  • Is something wrong?
#5,937 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
backend, distributed-systems

Research direction

Start at MeshWeaver.AI.MeshOperations.TryResolveUnifiedPath in MeshOperations.cs:1342 and read the Router Traffic Detection seam table. Check how the GetDataRequest is posted and whether the target is the owning node; use ReadIssuingHub() for the bounded read. Also inspect why RouterAsRouterCapableReceiverRatchetGuard did not flag this call. Done when the read avoids router delivery and the guard behavior is understood.

Written by the indexing model from the issue text.

Description

bug sev:M

What is failing

MeshOperations.TryResolveUnifiedPath issues its one-shot read (a GetDataRequest on the MeshOperations facade — unified-path resolution, used by the MCP verbs and page previews) through the bare DI-injected IMessageHub, which in the root container is the mesh hub. The request is posted with the router as both sender and target, so the read executes on the router's own action block and its response returns to the router — the same mechanism as the 2026-06-11 portal wedge, where work on the router's block starved real SubscribeRequest traffic.

Probable cause (high confidence on the shape, from the frames and the architecture record; the source is not in this mesh, so the call site itself needs one look)

This incident is the response half of the pair: DataExtensions.<HandleGetDataRequest>b__4 (DataExtensions.cs:3339) is the framework answering via ResponseFor(delivery) — the innocent answering half, since a reply goes where the request came from. The requester half was fingerprinted in the same second on the same pod (sibling incident Admin/_LogIncident/767f3a18a347248f) and names the offender: MeshOperations.TryResolveUnifiedPath (MeshOperations.cs:1342) posting via hub.Observe off the bare hub field. That field is proven to be the router in production (#4463: RecycleCore's DisposeRequest off the identical field). Fixing the requester — hop the read onto MeshExtensions.ReadIssuingHub() (the seam for a bounded one-shot READ) and address it at the owning node rather than mesh/{id} — silences both reports at once; both seams are the identity function for a non-router hub, so this is a no-op everywhere else.

Impact

One (role, type) report on one portal pod. Note the origin site reports once per role+type per hub lifetime, so this is one call-site class, not one event — the path runs on every render that resolves a unified path. Nothing user-visible is broken today; the cost is router-block contention, which is silent until a burst wedges the portal.

Where to look

  • MeshWeaver.AI.MeshOperations.TryResolveUnifiedPath — MeshOperations.cs:1342 — the hub.Observe(...) posting the GetDataRequest.
  • Router Traffic Detection — the seam table and the role-dependent remedy; ReadIssuingHub() is the right seam for this delivery, and hopping a subscription onto it would be the silent-loss failure mode, so the seam choice here matters.
  • Worth checking why RouterAsRouterCapableReceiverRatchetGuard did not flag this file: MeshOperations.cs has declared its hub router-capable since #4477 hopped RecycleCore on the same field, so a bare targeted post from it should be in that guard's denominator — unless this post's target spelling falls into the structural self-directed exclusion.

Related

  • Sibling incident Admin/_LogIncident/767f3a18a347248f (the GetDataRequest requester half) — same defect, one ticket can close both.
  • #4463 (same field, DisposeRequest — the production proof the field is the router), #4477 (the hop on the sibling line). Not a duplicate of any filed issue.
Evidence
Fingerprint a54028d6db3a0c43
Category MeshWeaver.Messaging.MessageHub
Severity Error
Top frame MeshWeaver.Data.DataExtensions+<>c__DisplayClass57_0.<HandleGetDataRequest>b__4 (DataExtensions.cs:3339)
Namespace memex
Pods memex-portal-deployment-65b5c866cd-6bkwh
Occurrences 1
First seen 2026-10-01 00:20:11Z
Last seen 2026-10-01 00:20:11Z
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-01 00:20:11Z memex-portal-deployment-65b5c866cd-6bkwh fail: MeshWeaver.Messaging.MessageHub[0]
      ROUTER_TRAFFIC ORIGIN: GetDataResponse was POSTED with the mesh hub as sender AND target (sender: mesh/iPPS4W--bUmoMZQ9pd0ZTQ, target: mesh/iPPS4W--bUmoMZQ9pd0ZTQ). 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.Data.DataExtensions+<>c__DisplayClass57_0.<HandleGetDataRequest>b__4 (DataExtensions.cs:3339)
         at System.Reactive.AnonymousSafeObserver`1.OnNext
         at System.Reactive.Linq.ObservableImpl.Take`1+Count+_.OnNext
         at System.Reactive.Linq.ObservableImpl.SelectMany`2+ObservableSelector+_+InnerObserver.OnNext
         at System.Reactive.SafeObserver`1+WrappingSafeObserver.OnNext
         at System.Reactive.Concurrency.Synchronize`1+_.OnNext
         at System.Reactive.Subjects.Fa…[truncated]

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

Dominant language
C#
Stars
12
Forks
5
Avg merge
4h 15m
Merged PRs (30d)
969

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Systemorph/MeshWeaver

All issues in Systemorph/MeshWeaver

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.