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

AI content-save exchange puts the mesh router on both ends: SaveContentResponse answered back onto the router by HandleSaveContent

Open
  • Is something wrong?
#6,646 2 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
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend

Research direction

Read AIExtensions.cs at line 204 and trace how the response target is derived from the incoming delivery; this distinguishes an answering response from an explicitly chosen router target. Then compare with ContentCollectionPlugin.cs at line 142 and the Router Traffic Detection guidance, including its named test fixture. Done means identifying which side owns the router delivery and correcting that path; the issue does not establish that the save failed or that the behavior recurs.

Written by the indexing model from the issue text.

Description

bug sev:M

Observed

One request/response exchange on the memex-cloud pod, 2026-10-12T23:20:57Z, put the mesh router on both ends of an AI content save:

  1. Request (sibling incident 262d20ded4c888f5): SaveContentRequest was POSTED with the mesh hub (mesh/Pzw3Ylzty0e946KWrAGV4g) as sender, target OIB/PowerBIExtracts, call site MeshWeaver.AI.Plugins.ContentCollectionPlugin.UploadContent (ContentCollectionPlugin.cs:142) — invoked through Microsoft.Extensions.AI.AIFunctionFactory reflection, i.e. an AI tool call.
  2. Response (this incident): SaveContentResponse was POSTED with the mesh hub as target (sender OIB/PowerBIExtracts), call site MeshWeaver.AI.AIExtensions+<>c__DisplayClass2_0.<HandleSaveContent>b__1 (AIExtensions.cs:204), on a Reactive SelectMany continuation.

Same two addresses, same second, same pod — these are not independent defects; they are the two halves of one delivery. The receiver-side echo of item 2 is sibling incident 30c9a3cc740b2a91 (same payload, no call site), and the burst's cross-hub RawJson receiver line was folded into 2a40878fdda81b44, already filed as Systemorph/MeshWeaver#5620.

Where and when

One occurrence, one pod, a single exchange — first and last sighting at 23:20:57Z. Note the detector dedups once per (role, type) per hub lifetime, so one line per role does not mean one event: sustained traffic of this shape would keep printing exactly one line per hub restart.

Impact

The response is delivered to and executed by the root mesh hub — the router, whose action block must only route (Router Traffic Detection; the 2026-06-11 wedge family). Whether the UploadContent tool invocation ever received its save confirmation is not established from this evidence. One sighting on one pod; no user-visible failure observed.

Not established

  • Whether HandleSaveContent echoed the request's sender (ResponseFor(delivery)-style) or chose the mesh hub as the response target — the origin line cannot separate the two "target" populations.
  • Whether the save on OIB/PowerBIExtracts itself succeeded.
  • Whether this exchange recurs (the once-per-hub-lifetime dedup masks recurrence until the hub restarts).
  • Whether other message types on the same path show the same shape.

Candidate causes and the reading that separates them

  1. The answering half of a router-issued request (the evidence favours this). The response's target is byte-identical to the request's sender, in the same second — a response goes where the request came from. If so, HandleSaveContent is the innocent answering half, and the defect is the request side: ContentCollectionPlugin.UploadContent posting SaveContentRequest from the DI-injected IMessageHub, which in the root container is the router (covered by sibling 262d20ded4c888f5; ContentCollectionPlugin resolves as a mesh-singleton plugin service, the exact caller class the rulebook names as needing a seam). Discriminating reading: AIExtensions.cs:204 — the target of the response post derives from the incoming delivery rather than being constructed there.
  2. An explicit choice of the router as response target. If the post at AIExtensions.cs:204 names the mesh hub itself, this call site is an offender in its own right, independent of the request side. Discriminating reading: the same one look — what the WithTarget/response construction at that line reads from.

Where to look

  • MeshWeaver.AI.AIExtensions, HandleSaveContent lambda (AIExtensions.cs:204) — the call site this line names; the one look that separates the two candidates above.
  • MeshWeaver.AI.Plugins.ContentCollectionPlugin.UploadContent (ContentCollectionPlugin.cs:142) — the request side of the same exchange, sibling incident 262d20ded4c888f5.
  • Router Traffic Detection — the role-dependent reading of a target line (the two populations with opposite ownership) and the pinned test fixture RouterTrafficOnNodeCreateFromTheRootHubTest for reproducing router-end exchanges from the root hub.
  • Sibling incidents to consolidate against: 262d20ded4c888f5 (request origin — this is the offender if candidate 1 holds), 30c9a3cc740b2a91 (receiver-side duplicate of this response, closeable against this ticket), 2a40878fdda81b44 / MeshWeaver#5620 (the folded RawJson line from the same burst).
Evidence
Fingerprint 530ff78477238090
Category MeshWeaver.Messaging.MessageHub
Severity Error
Top frame MeshWeaver.AI.AIExtensions+<>c__DisplayClass2_0.<HandleSaveContent>b__1 (AIExtensions.cs:204)
Namespace memex-cloud
Pods memex-portal-deployment-5897c49648-jtqxn
Occurrences 1
First seen 2026-10-12 23:20:57Z
Last seen 2026-10-12 23:20:57Z
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-12 23:20:57Z memex-portal-deployment-5897c49648-jtqxn fail: MeshWeaver.Messaging.MessageHub[0]
      ROUTER_TRAFFIC ORIGIN: SaveContentResponse was POSTED with the mesh hub as target (sender: OIB/PowerBIExtracts, target: mesh/Pzw3Ylzty0e946KWrAGV4g). 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.AI.AIExtensions+<>c__DisplayClass2_0.<HandleSaveContent>b__1 (AIExtensions.cs:204)
         at System.Reactive.AnonymousSafeObserver`1.OnNext
         at System.Reactive.Linq.ObservableImpl.SelectMany`2+ObservableSelector+_+InnerObserver.OnNext
         at System.Reactive.Linq.ObservableImpl.ReturnImmediate`1.Run
         at System.Reactive.BasicProducer`1.SubscribeRaw
         at System.Reactive.Linq.ObservableImpl.SelectMany`2+ObservableSelector+_.SubscribeInner
         at System.Reactive.Linq.ObservableIm…[truncated]

Opened automatically from Admin/_LogIncident/530ff78477238090. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 86529185e3af081f: 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 19m
Merged PRs (30d)
932

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.