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

AI content-collection upload tool posts its SaveContentRequest from the mesh router (ContentCollectionPlugin.UploadContent)

Aperta
  • Qualcosa non va?
#6,647 2 commenti 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
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
backend

Direzione di ricerca

Read ContentCollectionPlugin.cs at line 142 to see which hub UploadContent uses for its post, then inspect the plugin's DI registration and the AI harness's tool resolution to determine which provider supplies it. The issue does not establish the cause, so compare those findings with the candidate shapes described here. Done means confirming the cause and identifying the appropriate posting hub; AIExtensions.cs line 204 is the answering half and is not identified as a change site.

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

Descrizione

bug sev:M

Observed

On memex-cloud pod memex-portal-deployment-5897c49648-jtqxn, at 2026-10-12T23:20:57Z, the ROUTER_TRAFFIC ORIGIN detector at MessageHub.Post reported a SaveContentRequest posted with the mesh hub mesh/Pzw3Ylzty0e946KWrAGV4g as sender, addressed at the node OIB/PowerBIExtracts. The posting stack's first application frame is MeshWeaver.AI.Plugins.ContentCollectionPlugin.UploadContent (ContentCollectionPlugin.cs:142), reached through Microsoft.Extensions.AI.AIFunctionFactory's reflective tool invocation — the post happens while executing an AI agent tool call.

Two sibling reports in the same second complete the delivery family: the target's MeshWeaver.AI.AIExtensions+<>c__DisplayClass2_0.<HandleSaveContent>b__1 (AIExtensions.cs:204) answered with a SaveContentResponse addressed back at mesh/Pzw3Ylzty0e946KWrAGV4g — seen at the origin site (incident Admin/_LogIncident/530ff78477238090) and at the receiver (Admin/_LogIncident/30c9a3cc740b2a91). Per the detector's own role taxonomy, the response half is the answering half echoing the request's sender (ResponseFor(delivery)); the request's sender is the only end a caller chooses, and this report names the caller that chose it.

Where and when

One report, one pod, one instant. Note the detector's dedup: the origin line prints once per (role, type) per hub lifetime, so a single count does not establish how often the tool posts this way — further invocations of UploadContent on the same pod process would print no additional line. Other pods were not read.

Impact

The write itself appears to have completed — the request reached OIB/PowerBIExtracts and a response came back. What was observed is the documented router-traffic cost: an AI-tool content write with the router on the sender end, and its response handled on the router per the receiver-side line. At this volume that is noise; the documented failure mode of this shape is routing starvation under burst (the 2026-06-11 wedge). No user-visible failure is in evidence.

Not established

  • The cause is not established. The source of ContentCollectionPlugin was not readable from this mesh, so I could not read what hub reference the post at ContentCollectionPlugin.cs:142 uses, nor the plugin's DI registration. Which container resolved the plugin (and therefore whether its injected IMessageHub is the root mesh hub) is not on the incident.
  • Whether it still occurs, whether other pods or the control instance show the same fingerprint, and whether other log sites accompany it — not read.
  • Whether SaveContentRequest is inside either src/ ratchet's denominator: it is not a lifecycle message (not among the two handler-registration families the guards derive from), and if the file has never called a seam it declares nothing — consistent with the documented uncovered class ("a plain service handed the root hub"), for which the runtime ORIGIN line is the only instrument. That is context, not cause.

Candidate causes and the reading that separates them

  1. UploadContent posts off its DI-injected IMessageHub, which is the root mesh hub because the plugin is resolved from the root container — the mesh-singleton shape of #4463/#5747. Predicts: every invocation of the tool posts with the router as sender, from any pod. Reading that settles it: the source at ContentCollectionPlugin.cs:142 — whether the post's receiver is the bare injected hub or a seam — answers this in one look.
  2. The plugin is registered scoped but the AI tool dispatcher resolves it from the root provider — the #5900 shape ("scoped" does not mean "per hub" once the root provider resolves). Predicts: the same tool driven from a session hub would not report. Reading: the plugin's DI registration plus which provider the AI harness resolves tools from.
  3. The #5937 default-to-router shape (target fell back to the facade's own address) does not fit this report: the target here is a real node, OIB/PowerBIExtracts, not the router.

Where to look

  • MeshWeaver.AI.Plugins.ContentCollectionPlugin.UploadContent (ContentCollectionPlugin.cs:142) — the posting frame this report names.
  • MeshWeaver.AI.AIExtensions.HandleSaveContent (AIExtensions.cs:204) — the answering half; per the taxonomy there is nothing to change there, it replies to wherever the request came from.
  • Doc/Architecture/RouterTrafficDetection — the detector's two sites, the role taxonomy, and the prior same-family sightings: #4463, #5900, #5620, #5747.
  • Sibling incidents Admin/_LogIncident/530ff78477238090 and Admin/_LogIncident/30c9a3cc740b2a91 cover the response half of this same delivery and are likely the same defect — a human can close them against this ticket.

Severity note: judged sev:M as a clear defect with silent recurrence under the once-per-hub dedup; a human may re-rule to sev:L on the single sighting and the absence of functional failure.

Evidence
Fingerprint 262d20ded4c888f5
Category MeshWeaver.Messaging.MessageHub
Severity Error
Top frame MeshWeaver.AI.Plugins.ContentCollectionPlugin.UploadContent (ContentCollectionPlugin.cs:142)
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: SaveContentRequest was POSTED with the mesh hub as sender (sender: mesh/Pzw3Ylzty0e946KWrAGV4g, target: OIB/PowerBIExtracts). 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.Plugins.ContentCollectionPlugin.UploadContent (ContentCollectionPlugin.cs:142)
         at System.RuntimeMethodHandle.InvokeMethod
         at System.RuntimeMethodHandle.InvokeMethod
         at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method
         at System.Reflection.MethodBaseInvoker.InvokeWithManyArgs
         at System.Reflection.RuntimeMethodInfo.Invoke
         at Microsoft.Extensions.AI.AIFunctionFactory+ReflectionAIFunction+<InvokeCoreAsync>d__28.MoveNext
         at System.Runtime.…[truncated]

Opened automatically from Admin/_LogIncident/262d20ded4c888f5. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 14552096adb6a3c6: 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
5h 34m
PR unite (30g)
960

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.