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

Thread chat's agent-list subscription faults when it attaches to an already-released synced query in MeshNodeStreamCache

Closed
  • Is something wrong?
#5,771 33 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend, observability

Research direction

Read the agent-list subscription and error handler in ThreadChatView, then inspect the synced-query lookup and released-entry cleanup in src/MeshWeaver.Hosting/MeshNodeStreamCache.cs. First establish whether a disposed owner can remain reachable; the issue says pod lifecycle evidence around 2026-09-26 18:26:06Z could distinguish teardown from a stale handle. Done when the cause is resolved and the view handles this case appropriately; the issue does not specify whether to resubscribe or end quietly.

Written by the indexing model from the issue text.

Description

bug sev:L

What is failing

ThreadChatView (Blazor thread chat) subscribes to the agent-list synced query (AiSettings|<user>, served by the silo's MeshNodeStreamCache). In this case the subscription arrived after the query's owner had already let go of its shared connection. The cache refused it with ObjectDisposedException ("the owner is disposed, its upstream is unsubscribed…"). The view's agent-list stream terminated, and the view logged that at Error.

Probable cause (low-to-medium confidence)

The refusal itself is deliberate. Since the change that gave every shared subscription an owner (A shutdown releases every shared subscription it owns), the cache fails fast on a subscriber that arrives after the owner is disposed. Before that change, such a subscriber would have waited on a replay that nothing feeds. So the open question is why a live chat view was still subscribing at that point. There are two explanations, and the evidence cannot tell them apart:

  1. Shutdown or recycle race (benign). The pod's cache (or the hub that owns the query) was being disposed while a Blazor circuit was still rendering the chat. In that case the only defect is that ThreadChatView logs an expected teardown at Error, and it should treat ObjectDisposedException from this source as end-of-life.
  2. Stale query handle (real defect). The query entry for AiSettings|<user> was released (idle, or owner torn down) but stayed reachable, so a new subscriber was handed the released owner instead of a freshly created one. That would mean the agent picker in a live chat silently stops populating until reload.

I could not confirm pod shutdown at 18:26:06Z from the evidence available. Checking the pod's lifecycle around that timestamp settles which case this is.

Impact

Minimal as observed: one occurrence, one pod, one user's chat. At worst, that chat's agent list stopped updating until the page was reloaded. No data is affected.

Where to look

  • ThreadChatView (MeshWeaver.Blazor.Chat): the agent-list query subscription and its error handler (the [ThreadChat:…] the agent list query terminated log site). Decide whether an ObjectDisposedException there should re-subscribe, or end quietly at Debug.
  • src/MeshWeaver.Hosting/MeshNodeStreamCache.cs: the synced-query path that raises "has released the shared connection this subscription would ride". Verify that a released query entry is removed from lookup, so the next reader creates a new one and does not hit the disposed owner. Background: Mesh Node Stream Cache, Synced Mesh Node Queries.

No existing incident covers this log site. It is related in spirit to other teardown-time ObjectDisposedException incidents, but it is not a duplicate of any of them.

Evidence
Fingerprint 4e48b3826646ffe0
Category MeshWeaver.Blazor.Chat.ThreadChatView
Severity Error
Exception System.ObjectDisposedException
Namespace memex-cloud
Pods memex-portal-deployment-6c7669df84-9b4rz
Occurrences 1
First seen 2026-09-26 18:26:06Z
Last seen 2026-09-26 18:26:06Z
Routing not determined — no configured route matches the category MeshWeaver.Blazor.Chat.ThreadChatView. 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-09-26 18:26:06Z memex-portal-deployment-6c7669df84-9b4rz fail: MeshWeaver.Blazor.Chat.ThreadChatView[0]
      [ThreadChat:38be5244] the agent list query terminated
      System.ObjectDisposedException: MeshNodeStreamCache query 'AiSettings|sglauser' has released the shared connection this subscription would ride: the owner is disposed, its upstream is unsubscribed, and a subscriber arriving now would otherwise wait on a replay nothing will feed.
      Object name: 'MeshNodeStreamCache query 'AiSettings|sglauser''.

Opened automatically from Admin/_LogIncident/4e48b3826646ffe0. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site b395d7e82e28bc16: 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 50m
Merged PRs (30d)
949

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.