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

Hub teardown during OgCard live-update discarded a GetDataResponse still deferred behind EventHub initialization gates

Aperta
  • Qualcosa non va?
#6,791 16 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@rbuergi ci sta già lavorando.

Dal 15/10/2026.

  • #6802 di @rbuergi — aperta

Valutazione

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

Direzione di ricerca

The log site is MeshWeaver.Messaging.MessageService event 7301 ([DISPOSE-DISCARD]), but its source is not in the readable partitions, so start by locating it in the MeshWeaver repository. Check whether the discard path drains deferred GetDataResponse messages before a hub disposes, and whether it is reached from the ModuleLiveUpdate/RecycleCascade path. Linked PR #6802 already targets this area, so review it before starting. Done means a reproduction or reasoned explanation of why Marketing/EventHub disposed with its init gates still closed.

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

Descrizione

bug sev:L

Observed

A hub teardown discarded accepted-but-deferred work. Hub Marketing/EventHub (namespace memex-cloud, pod memex-portal-deployment-6d4df8d45f-ktwf2) was disposing while a GetDataResponse message (id kU80TxqKCEiknJTradXWKw, from sender Marketing) was still parked behind its initialization gates (DataContextInit, MeshNodeInit). The message was not processed; the sender was answered ShuttingDown.

The teardown itself was a DisposeRequest routed from portal/nodeops-CQIqeIjW80aQ96e3VctZHg, cascading from a ModuleLiveUpdate: MeshWeaver.OgCard was swapped live from /tmp/meshweaver-pinned-modules/1-653fa26e/MeshWeaver.OgCard@3e4a5ae1ef9d780f — a self-update with "a landed module generation pending activation". The log site is MeshWeaver.Messaging.MessageService (fail level, event id 7301), and its own text states the invariant that was violated: accepted work must be drained before a hub goes down.

Where and when

Single occurrence, single pod, at 2026-10-15T00:48:09Z — one instant, not a burst. It coincides exactly with an OgCard live module swap triggering a RecycleCascade of dependent hubs. Whether this fires at every module live-update with in-flight requests, or only this once, cannot be told from one sample.

Impact

One GetDataResponse to a Marketing-side sender was dropped; the sender did receive a definitive ShuttingDown answer rather than silence. No data-loss or corruption signal; nothing indicates the request was not re-issued after the hub came back. The concrete user-visible effect, if any, was not established.

Not established

  • Cause. The evidence shows which teardown dropped which deferred message, not why the work was still behind the gates when the hub went down.
  • Whether this still occurs, or is a one-off race.
  • Whether other hubs in the same RecycleCascade discarded deferred work at the same instant — only this one site reached this watcher in the window.
  • Whether Marketing/EventHub's gates had been closed a long time (slow/stuck init) or closed only momentarily.
  • The MeshWeaver.Messaging source is not present in the mesh partitions readable from this incident thread, so the log site could not be opened and no file/method can be named from direct reading.

Candidate causes and the reading that separates them

  1. Request raced the recycle. The GetData request/response pair arrived during the teardown window, after the drain phase had already passed, so the drain never saw it. Predicts: the original GetData request's timestamp is within the same second as the OgCard swap, and recurrences are proportional to module live-update frequency. Discriminating reading: the sender-side (Marketing) log around 00:48:09 showing when the request was issued, versus the OgCard swap timestamp.
  2. Hub init never completed. EventHub was stuck behind DataContextInit/MeshNodeInit since before the swap — the response sat deferred indefinitely and the recycle merely ended its wait. Predicts: initialization logs for Marketing/EventHub stretching back well before the swap, with no gate-completed line. Discriminating reading: the hub's earlier log lines (or its node state at last check-in) showing when its init began and whether gates ever closed.
  3. Drain ordering vs. cascade ordering. The RecycleCascade from the module swap routes DisposeRequests to dependent hubs before their deferred queues can drain, i.e. the discard is systemic to the live-update path rather than a one-off race. Predicts: the same DISPOSE-DISCARD fingerprint (this log site, any hub path) at every ModuleLiveUpdate swap on any pod. Discriminating reading: query the same log site over the last several live updates (the OgCard generation dir 1-653fa26e can be matched in prior swap lines).

Where to look

  • Log site: MeshWeaver.Messaging.MessageService, event id 7301, category MeshWeaver.Messaging.MessageService.
  • Hub: Marketing/EventHub; sender: Marketing; teardown requester: portal/nodeops-CQIqeIjW80aQ96e3VctZHg.
  • Trigger chain: ModuleLiveUpdate → RecycleCascade from 'Marketing/Event' → routed DisposeRequest.
  • Module: MeshWeaver.OgCard, generation /tmp/meshweaver-pinned-modules/1-653fa26e/….
  • No duplicate found: no prior incident or issue at this component/symptom was visible in the readable partitions.
Evidence
Fingerprint 6e3296e76a1e4431
Category MeshWeaver.Messaging.MessageService
Severity Error
Namespace memex-cloud
Pods memex-portal-deployment-6d4df8d45f-ktwf2
Occurrences 1
First seen 2026-10-15 00:48:09Z
Last seen 2026-10-15 00:48:09Z
Routing not determined — no configured route matches the category MeshWeaver.Messaging.MessageService. 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-15 00:48:09Z memex-portal-deployment-6d4df8d45f-ktwf2 fail: MeshWeaver.Messaging.MessageService[7301]
      [DISPOSE-DISCARD] Hub Marketing/EventHub is disposing with GetDataResponse (id=kU80TxqKCEiknJTradXWKw, from Marketing) still deferred; initialization gates closed at deferral: [DataContextInit,MeshNodeInit] — the message is NOT processed; the sender is answered ShuttingDown. RunLevel=ShutDown. This teardown was requested by portal/nodeops-CQIqeIjW80aQ96e3VctZHg (routed DisposeRequest); why: RecycleCascade from 'Marketing/Event': ModuleLiveUpdate: MeshWeaver.OgCard swapped live to /tmp/meshweaver-pinned-modules/1-653fa26e/MeshWeaver.OgCard@3e4a5ae1ef9d780f/MeshWeaver.OgCard.dll — self-update: a landed module generation is pending activation. Accepted work must be drained before a hub goes down — that attribution is who to ask why this hub went down with work still parked behind its gates. Request: GetDataResponse

This log site's previous ticket, https://github.com/Systemorph/MeshWeaver/issues/6733, was closed about a different fingerprint, and this fault fired after that close. It is left closed: an occurrence of this fingerprint is no evidence that the fault it was closed for came back. This issue now tracks the log site, and later fingerprints of it fold in here.

Opened automatically from Admin/_LogIncident/6e3296e76a1e4431. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 68a7699745069b20: 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.