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

DataChangedEvent handler on a sync sub-hub wedged for 15s during Dispose — first genuine [DISPOSE-WEDGE] (7311) verdict; find what the handler blocks on

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend

Research direction

Start with the Disposal Stall Verdict, Hub Disposal Model, and Teardown Layers docs to understand the 7311 snapshot and shutdown flow. Then trace the synchronous DataChangedEvent handler on the synchronization sub-hub, including SynchronizationStream/JsonSynchronizationStream and the disposal registrants; inspect MessageHub.OnDisposalStall and MessageService for watchdog context. The issue is resolved when the blocking wait is identified and the cause of the lost notification is understood; the log does not identify the wait target.

Written by the indexing model from the issue text.

Description

bug sev:M

What is failing

During a hub Dispose() cascade, the DataChangedEvent handler on a sync/* sub-hub held the action block for over 15 s with no progress — after ~40 turns had already completed since Dispose(), with turns still queued behind it. The disposal-stall watchdog reached its wedged-turn verdict (event 7311) and cancelled the turn's token, so the shutdown behind it proceeded — but the work of that turn did not finish: one change notification was never delivered.

Probable cause — moderate confidence on the shape, low on the target

The snapshot is internally consistent for a live turn (Executing(DataChangedEvent, …) together with drainsInFlight=1 and draining=True), so a handler was genuinely on the block — this is not the stale-stamp shape of the 2026-09-19 sighting (Executing with drainsInFlight=0 and draining=False), and not the #3593 M1 pump stall (drainsInFlight=0, nothing dequeued, nothing executing). DataChangedEvent is handled on the synchronization sub-hub synchronously, so a 15 s hold means the handler blocked on something: a lock convoy, blocking I/O, or a join on a peer hub torn down in the same cascade. Exactly what it waited on is not in the log — that is the open question this ticket exists to answer.

This verdict family is documented as deliberately left open: Reading a Disposal Stall Verdict states the M1 fix left M2-class wedges untouched and "the verdict still names them if they ever fire" — this appears to be that firing: the first production occurrence of 7311 with a self-consistent live-turn snapshot.

Impact

Single occurrence, one pod, one hub. Contained by design — the watchdog cancels the token so the teardown proceeds; the cost is one lost change notification during a teardown that was already in flight. Had the same turn persisted another budget, the 7312 "ignores cancellation" verdict would have followed.

Where to look

  • Reading a Disposal Stall Verdict — the verdict taxonomy, and the rule for reading Executing(T, ms) against drainsInFlight before believing the elapsed.
  • Hub Disposal Model and Teardown Layers — the shutdown state machine this verdict interrupts.
  • The DataChangedEvent handler on the synchronization sub-hub — SynchronizationStream / JsonSynchronizationStream, the disposal registrants the docs name as the dozen on a sync/* hub; check for a synchronous wait (lock, blocking I/O, or a join on a peer in the same cascade).
  • MessageHub.OnDisposalStall / MessageService — the watchdog that emitted the verdict.

Not a duplicate of #3593 (same log family, different bucket: that was the pump never running, this is a live handler wedged), but it is the same family and should be read against that page's discriminator table.

Evidence
Fingerprint 35d2036a25477a16
Category MeshWeaver.Messaging.MessageHub
Severity Error
Namespace memex
Pods memex-portal-deployment-6b555484b4-qjm86
Occurrences 1
First seen 2026-10-01 13:33:44Z
Last seen 2026-10-01 13:33:44Z
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 13:33:44Z memex-portal-deployment-6b555484b4-qjm86 fail: MeshWeaver.Messaging.MessageHub[7311]
      [DISPOSE-WEDGE] Hub sync/9zaPOVJDZEOJ_VIfe8Dw6A: the turn DataChangedEvent has held the action block for 15088ms with no progress (last progress: sync/9zaPOVJDZEOJ_VIfe8Dw6A → Started); RunLevel=Started, queue depth 4, 40 turn(s) completed since Dispose(). Cancelling its token so a cooperative handler returns and the shutdown behind it can proceed — the work of that turn did NOT finish. Find what it was waiting on; a turn that returns is never cancelled.
      Hub sync/9zaPOVJDZEOJ_VIfe8Dw6A RunLevel=Started Disposal=Pending Queue(buffer=4,deferred=0,drainsInFlight=1,openGates=0,draining=True,drainsAwaitingScheduler=0) Executing(DataChangedEvent, 15089ms) Registrants=6

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