CollaborativeMarkdownView document load times out — SubscribeRequest forwarded through cache and mesh hubs but never handled

Aperta
  • Qualcosa non va?
#7,842 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
distributed-systems

Direzione di ricerca

The payload names no source file for the message routing path, so start from the MeshWeaver.Blazor.Components.CollaborativeMarkdownView log site and the SubscribeRequest trail (cache hub, then mesh hub, ending at ROUTED onTarget=False). Before any fix, establish which of the three candidate causes holds by reading the target hub's RunLevel and queue at the failure instant. Done means a reproducible cause is identified and linked to MeshWeaver#2896 or ruled out, with the owning maintainer's agreement on the fix.

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

Descrizione

bug sev:M

Observed

Loading a Markdown document in the portal (MeshWeaver.Blazor.Components.CollaborativeMarkdownView, document {path}, Area {path}) failed with System.TimeoutException: a SubscribeRequest (id 9tP22oq0k0OcLGcqBN4iFA) aimed at that document received no reply within 60 s.

The delivery trail on the sample shows the request was accepted at both the caller's cache hub (RunLevel=Started, queued at depth 5) and the mesh hub (RunLevel=Started, queued at depth 7), then ROUTED onTarget=False state=Forwarded — twice — and nothing further: no handler was ever entered for the target. The caller's own hub was demonstrably healthy throughout: it handled 484 messages while waiting, and its queue was empty at the moment it gave up.

The target document is not missing or deleted: {path} exists (Markdown, Active, version 68, last written the same day, hours before the failure). This distinguishes it from the earlier CollaborativeMarkdownView failures on deleted targets ({path}#6080, #6076).

Where and when

A single occurrence at a single instant, on one pod of the memex deployment. No burst, no steady rate. Nothing I read ties it to a roll, restart or sync. The incident queue holds no other incident for this fingerprint.

Impact

One user's collaborative view of one document failed to load once; a read timed out — nothing was written or lost. Whether a reload recovers was not verified.

Not established

  • The cause. All three of the candidate causes below fit the trail as far as it goes; queue state on the caller does not separate them.
  • Whether it repeated. Only one sighting exists; I could not check the raw log archive for the same signature outside the watcher window, nor whether other documents on the same pod showed it.
  • What the second ROUTED onTarget=False entry means — a re-forward (loop) or a second trail record of the same hop.
  • Whether this is a recurrence of the wedged-hub class seen on the same instance (see below).

Candidate causes and the reading that separates them

  1. {path}: the mesh hub accepts the request but never delivers it to the hub that owns {path} (onTarget=False on both ROUTED entries). Predicts: the target hub is healthy and idle, and a direct read of the node succeeds while the view fails. Reading: the target hub's own RunLevel and queue at the instant.
  2. Wedged target hub — the class of MeshWeaver#2896 ("a per-node hub that stops answering"), which the timeout message itself names. Predicts: the target hub shows a long-running Executing entry or a growing queue, and reads of the node time out from every session. Reading: same — the target hub's {path} is the discriminator the log text itself points to.
  3. Reply lost: the handler ran but its reply never reached the caller. Predicts: the document actually renders client-side despite the exception, and the target hub shows normal handled counts. Reading: client-side behaviour at the failure instant.

Possibly related, not established as the same defect: {path}#7477 — a space-root hub on the same memex instance stopped serving reads and writes, a recycle did not help, closed completed 2026-11-01 (one day before this sighting). This incident's caller hub was demonstrably processing and the target is an ordinary document, not a Space root, so a link is plausible but unproven. If it is the same defect class, the earlier incident's severity applies; if not, this is an isolated routing stall.

Where to look

  • The SubscribeRequest delivery path between the cache hub and the mesh hub: the trail ends at the mesh hub's ROUTED onTarget=False state=Forwarded step, so that {path} decision is where the request stalls. The Blazor view is only the caller; the failure is in message delivery.
  • I could not locate the framework source for this category in the mesh (searches returned nothing), so no file or method can be named from evidence — the known-issue references above (#2896, #7477, #6080/#6076) are the closest pointers.

Not a duplicate of any open item I could find: #6080/#6076 cover a deleted target (this one exists), #7477 covered a Space root (this is a document view) and is closed.

Evidence
Fingerprint 0cc148db45c3eced
Category MeshWeaver.Blazor.Components.CollaborativeMarkdownView
Severity Error
Exception System.TimeoutException
Namespace memex 1 occurrence(s), 2026-11-02 18:17:21Z → 2026-11-02 18:17:21Z; pods memex-portal-deployment-545f64dd65-l62ct
Occurrences 1
First seen 2026-11-02 18:17:21Z
Last seen 2026-11-02 18:17:21Z
Routing not determined — no configured route matches the category MeshWeaver.Blazor.Components.CollaborativeMarkdownView. 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-11-02 18:17:21Z memex-portal-deployment-545f64dd65-l62ct fail: MeshWeaver.Blazor.Components.CollaborativeMarkdownView[0]
      Loading document {path} in Area {path}
      System.TimeoutException: No response received in hub {path} within 00:01:00 for request SubscribeRequest (id=9tP22oq0k0OcLGcqBN4iFA) → target {path} This hub: RunLevel=Started Queue(buffer=0,deferred=0,openGates=0,drainsInFlight=0,draining=False,handledWhileWaiting=484). This hub is idle AT THE MOMENT IT GAVE UP — an instantaneous sample, which is why handledWhileWaiting above is printed beside it: that is the interval fact, and a hub that handled many messages was not idle throughout however empty its queue is now. Cause is UNKNOWN between: the target never received the request (routing), the target received it and is wedged (a per-node hub that stops answering — MeshWeaver#2896), or the target answered and the reply was lost. Queue state alone cannot distinguish them; the trail below can, and so can the target's own RunLevel and queue. Trail: AWAITING SubscribeRequest→{path}(+0ms) → POSTED target={path}(+0ms) → RECEIVED runLevel={path}(+0ms) → {path}(+0ms) → QUEUED queue=main depth={path}(+0ms) → RECEIVED runLevel={path}(+0ms) → {path}(+0ms) → QUEUED queue=main depth={path}(+0ms) → ROUTED onTarget=False state={path}(+0ms) → ROUTED onTarget=False state={path}(+0ms)  ⇒ the delivery reached a hub but no handler was ever entered — it is still being routed, or it was accepted and never executed.

This log site's previous ticket, https://github.com/Systemorph/MeshWeaver/issues/7495, 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/0cc148db45c3eced. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site b14bf54a3cfd5963: 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 14m
PR unite (30g)
957

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.