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

Thread hub wedges in a claimed round that never starts — supervisor relaunches revive it into StartingExecution with no cell, then give up

Closed
  • Is something wrong?
#6,147 30 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
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend, observability

Research direction

Start with src/MeshWeaver.AI/Supervision/ThreadSupervisor.cs and the ThreadSubmission claim path under src/MeshWeaver.AI; read the Doc/Architecture/ThreadSupervision contract and related issue #2229. Then inspect the episode’s thread-node supervisor* fields and serving-pod logs around the last write and give-up. Done means establishing whether the hub died mid-claim or repeatedly re-claimed input, and documenting or addressing the confirmed cause.

Written by the indexing model from the issue text.

Description

bug sev:L

What is failing

The thread supervisor exhausted its two relaunches on Hosting/Triage/pull-request/systemorph-meshweaver-plugins-2793/_Thread/owner-systemorph-meshweaver-plugins-2793 — the internal triage owner thread of PR MeshWeaver.Plugins#2793 — and settled it at the bound. The node sat in StartingExecution with no active cell, no cross-hub write for 18 min against a 15-min relaunch bound, and no terminal state. The supervisor itself behaved exactly as designed (bounded retries, then settle-and-file); the defect is the wedge underneath: a thread hub that, once woken by the supervisor's write, claims its pending input but never starts the round.

Probable cause

Most likely the Plugins#2229 defect-C family, resurfacing bounded: each relaunch write activates the hub, whose submission watcher claims the pending message (StartingExecution, deliberately without stamping a timestamp), and the claimed round then produces neither a cell nor a write. The supervisor's clock sees only "unchanged", recycles and relaunches twice, and gives up — which is now correct behaviour, but means the wedge is never diagnosed. Confidence is moderate on the mechanism and low on root cause: the log line itself concedes the supervisor cannot distinguish a hub that is gone or wedged from one re-claiming the same input at hub speed, and nothing on the node establishes why the claimed round never advanced. Pod-level logs for the serving pod around the episode (last write 09:44:22Z, give-up at the next sweep) are needed to decide between a hub that died mid-claim and a claim that loops.

Impact

One thread, one pod, one occurrence in the fleet. The affected thread is an internal triage owner thread (the PR #2793 review round), not user content; its input was answered by the settle's diagnosis cell and resubmission is the available remedy. No evidence of the wedge on any other thread in the same window.

Where to look

  • src/MeshWeaver.AI/Supervision/ThreadSupervisor.cs (the give-up path) and the submission watcher's claim path in src/MeshWeaver.AI (ThreadSubmission — the deliberate no-timestamp claim cited in #2229). Contract: Doc/Architecture/ThreadSupervision.
  • The thread node's supervisor* fields for this episode (retries, note, feedback path).
  • Related, likely the same family: Systemorph/MeshWeaver.Plugins#2229 — defects A–D of the same supervisor, especially defect C (a claim re-arms a round that never advances). If this incident reproduces the claim-re-arm mechanism post-fix, that issue's history is the context; not a duplicate, since #2229's write-storm and re-settle defects are fixed and this is a new, bounded, single-occurrence recurrence of the underlying wedge.
  • A sibling incident at the same supervisor (a different log site, pending messages never ingested) fired in the same window and is triaged separately.
Evidence
Fingerprint 6a30883a3b9ef36e
Category MeshWeaver.AI.Supervision.ThreadSupervisor
Severity Error
Namespace memex
Pods memex-portal-deployment-848f664fd5-zzqll, memex-portal-deployment-848f664fd5-jgkbf, memex-portal-deployment-848f664fd5-zqfrh
Occurrences 55
First seen 2026-10-05 10:02:47Z
Last seen 2026-10-05 10:07:35Z
Routing not determined — no configured route matches the category MeshWeaver.AI.Supervision.ThreadSupervisor. 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-05 10:06:59Z memex-portal-deployment-848f664fd5-zzqll fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-memex-655/_Thread/owner-systemorph-memex-655 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:30Z (21 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:06:59Z memex-portal-deployment-848f664fd5-zzqll fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-meshweaver-plugins-2793/_Thread/owner-systemorph-meshweaver-plugins-2793 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:19Z (21 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:07:12Z memex-portal-deployment-848f664fd5-jgkbf fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-memex-655/_Thread/owner-systemorph-memex-655 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:30Z (22 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:07:12Z memex-portal-deployment-848f664fd5-jgkbf fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-meshweaver-plugins-2793/_Thread/owner-systemorph-meshweaver-plugins-2793 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:19Z (22 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:07:22Z memex-portal-deployment-848f664fd5-zqfrh fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-memex-655/_Thread/owner-systemorph-memex-655 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:30Z (21 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:07:22Z memex-portal-deployment-848f664fd5-zqfrh fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-meshweaver-plugins-2793/_Thread/owner-systemorph-meshweaver-plugins-2793 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:19Z (22 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:07:35Z memex-portal-deployment-848f664fd5-zqfrh fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-memex-655/_Thread/owner-systemorph-memex-655 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:30Z (22 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:07:35Z memex-portal-deployment-848f664fd5-zqfrh fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-meshweaver-plugins-2793/_Thread/owner-systemorph-meshweaver-plugins-2793 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:19Z (22 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:07:35Z memex-portal-deployment-848f664fd5-zzqll fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-memex-655/_Thread/owner-systemorph-memex-655 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:30Z (22 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see
2026-10-05 10:07:35Z memex-portal-deployment-848f664fd5-zzqll fail: MeshWeaver.AI.Supervision.ThreadSupervisor[0]
      [ThreadSupervisor] giving up on Hosting/Triage/pull-request/systemorph-meshweaver-plugins-2793/_Thread/owner-systemorph-meshweaver-plugins-2793 after 2 relaunch(es): StartingExecution on cell (none) with no cross-hub write to the node since 2026-10-05 09:45:19Z (22 min ago, bound 15 min) and no terminal state; a live hub force-idles a silent round in 90 s, so its hub is gone or wedged — or it is re-claiming the same input at hub speed, which this clock cannot see

Opened automatically from Admin/_LogIncident/6a30883a3b9ef36e. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site f81c4074d933ecf7: 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
5h 51m
Merged PRs (30d)
970

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.