ThreadChatView context resolution fails unhandled when the composer's bound context node was deleted — no error arm on the context chip

Closed
  • Is something wrong?
#6,081 3 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
1-2 days
Newbie friendliness
54/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, react
Domain
backend, frontend

Research direction

Read ThreadChatView.razor.cs at the context-resolution step that logs “Resolving the composer's context,” then inspect ComposerAccess.ObserveContextChip and the permission handling from #5372. Check how the deleted-node and address-not-found verdicts are represented, and compare the guard in clients/react/src/controls/threadChat.tsx. Done when deleted contexts no longer surface as Error and the composer renders without the missing context; verify permission behavior remains unchanged.

Written by the indexing model from the issue text.

Description

bug sev:M

What is failing

The composer's context-resolution step in ThreadChatView fails when the thread's bound context node no longer exists. The context-chip path (ComposerAccess, added by MeshWeaver.Plugins#2676) has no error arm for a context that has vanished: the mesh's not-found answer — the deleted-node verdict from the read layer, the address-not-found answer from the delivery layer — surfaces as an unhandled exception logged at Error, instead of dropping the context and rendering the composer without it.

Probable cause

High confidence. The concrete case is a thread in the Thread/1 area whose composer context points at Hardware/Workstations, a node that was deleted while the thread still referenced it. Minutes before this burst, the same session's context read failed with the mesh's terminal deleted-node answer (InvalidOperationException "the node was deleted", recorded on sibling incident Admin/_LogIncident/6c8b21eec1381339); this burst is the same condition surfacing through the delivery layer as a DeliveryFailureException ("No node found … Closest ancestor is 'Hardware'"). The view keeps resolving a context address that no longer exists and neither layer's not-found verdict is handled. This is precisely the residual recorded on the #5372 fix round: ObserveContextChip has no error arm, so anything but a clean permission answer reaches SurfaceError. The sample carries no stack beyond the log site, so the exact throwing read is inferred, not pinned.

Impact

Narrow on the evidence: one user session on one pod, this fingerprint plus its sibling at the same site. For the affected thread, the context resolution fails at Error every time the view opens until the context reference is cleared — the context chip is broken for that thread. No data loss; the mesh answers correctly. Any thread whose bound context node is later deleted will hit this, and the two exception flavors mean two fingerprints keep firing for one defect.

Where to look

  • The context-resolution step in ThreadChatView that logs Resolving the composer's context in Area {path} (the ThreadChatView.razor.cs file the #5372 code search located in Systemorph/MeshWeaver.Plugins). When the context read answers "the node was deleted" or the delivery answers "no node found", drop the context — render without the chip or with a "context gone" hint — and log below Error. Catch narrowly: recognize the two not-found verdicts; #5372's permission case stays its own arm.
  • ComposerAccess.ObserveContextChip (added by PR #2676) already drops a context the viewer cannot read; the deleted-context case needs the same treatment. The fix-round notes on /Hosting/Triage/issue/systemorph-meshweaver-5372 name this exact residual as the predicted recurrence of shape 2.
  • The mesh's deleted-node read semantics: Reading a deleted node answers "not found" straight away — treat the answer as "gone".
  • Check the React twin clients/react/src/controls/threadChat.tsx (Thread Chat in React) for the same missing guard.
  • Related, not duplicates: #5372 (unreadable context, permission — fixed by #2676) and #5962 (deleted thread node at the composer load — /Hosting/Triage/issue/systemorph-meshweaver-5962). This ticket is the deleted context node at context resolution — the same missing error arm #5372 predicted; a person may close it in seconds once #5962's planned catch is widened to the context step, or fold them if the fix lands as one guard.

Filed as sev:M: a clear defect on a secondary path (the context chip) with an easy workaround (clear/rebind the context or reopen the thread). Re-rule to sev:L if deleted contexts prove rare.

Evidence
Fingerprint 16bdfa2df3c74a43
Category MeshWeaver.Blazor.Chat.ThreadChatView
Severity Error
Exception MeshWeaver.Messaging.DeliveryFailureException
Namespace memex
Pods memex-portal-deployment-6dbcd749fb-ps2xz
Occurrences 1
First seen 2026-10-04 09:53:31Z
Last seen 2026-10-04 09:53:31Z
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-10-04 09:53:31Z memex-portal-deployment-6dbcd749fb-ps2xz fail: MeshWeaver.Blazor.Chat.ThreadChatView[0]
      Resolving the composer's context in Area Thread/1
      MeshWeaver.Messaging.DeliveryFailureException: No node found at 'Hardware/Workstations'. Closest ancestor is 'Hardware' (remainder='Workstations').

Opened automatically from Admin/_LogIncident/16bdfa2df3c74a43. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 207343f8c227365e: 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 10m
Merged PRs (30d)
980

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.