fix: the chat's thread lists were empty for everyone by rbuergi · Pull Request #1661 · Systemorph/MeshWeaver

rbuergi · 2026-08-16T09:02:34Z

Symptom

The Threads picker in the chat side panel lists nothing. Same for the in-thread nav menu's "other open threads".

Two independent defects, one symptom

1 — the picker was scoped to the page you're standing on. SwitchToResumeModeAsync queried
namespace:{NavigationService.CurrentNamespace}/_Thread. CurrentNamespace is the page's node path (LayoutArea stamps the top area's Address), and a thread is created under whatever node it was started from — so on any page that never hosted a thread of its own, the picker asked for a namespace that holds nothing. Verified against memex: nodeType:Thread namespace:Doc/Architecture/AsynchronousCalls/_Thread → 0 results, while nodeType:Thread content.createdBy:rbuergi → the user's threads across every partition.

2 — the nav menu filtered on a field that is structurally null. SetupMyThreadsSubscription asked the server for every thread and then kept the ones where n.CreatedBy == me. Threads live in the _Thread satellite table, and the authorship columns exist only on mesh_nodes — a satellite read projects NULL::text AS created_by (PostgreSqlStorageAdapter.AuthorCols). So MeshNode.CreatedBy is null on every thread that arrives, and that predicate was false for every row, for every signed-in user. (Confirmed on live data: a thread node returns no createdBy; a mesh_nodes node does.)

The subtlety that makes #2 easy to get wrong: the server-side createdBy: term is fine — the query layer maps it onto the stored content. Only the projected value is null.

The fix

One place, MeshWeaver.AI/ThreadQueries.cs, holding the two rules that are invisible at the call site:

ownership is decided by the query (content.createdBy) — the same predicate the dashboard's thread query already uses and that CrossPartitionThreadQueryTests already pins — never re-filtered in the client;
a thread list is not scoped to the current page.

MyThreads / MyOpenThreads / ThreadsUnder now back the picker, the nav menu and the sub-thread list.

"Don't we have tests for it?" — we did not, and that's why it broke twice

Nothing covered these two lists. What existed: CrossPartitionThreadQueryTests (the dashboard's thread query — the same content.createdBy lesson, learned once and pinned for one call site only), SyncedQueryProjectionContractTest (the select: contract, added after b78cfe9 — the previous time this same picker silently returned nothing), and ThreadResumeTest (loading one thread's messages). The chat's lists were hand-written query strings that no test touched.

New ThreadListQueryTests (real PG-backed mesh, workspace.GetQuery — the production path) pins:

a thread started on an ordinary content page is found by "my threads" (kills the page scoping);
another user's thread is not;
Done drops out of MyOpenThreads but stays in MyThreads (also pins that the status enum matches by name);
the row arrives with no envelope authorship at all, so re-filtering it client-side drops everything — the trap that only reproduces on PG.

Each test owns a unique creator id, so the deliberately unscoped cross-partition query matches only its own rows (no #834-style paging flake).

Verification

dotnet build -c Release -warnaserror clean: MeshWeaver.Blazor.Portal (builds MeshWeaver.AI), MeshWeaver.Hosting.PostgreSql.Test.
ThreadListQueryTests — 4 passed against a real Postgres container. (First run caught a wrong claim in my own test — that the server-side envelope term matches nothing — which is how the "server-side is fine, the value is null" distinction above got established.)
Not visually confirmed in a running portal; the queries are pinned by the tests above.

Left alone deliberately

ChatHistorySelector.razor carries the same createdBy:{userId} shape but is referenced nowhere — dead code. Its server-side term is in fact correct; it wants deleting rather than editing, which is a separate call.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KmBFaHTqhy7h742wkAaJKj

Two lists, two independent defects, one symptom ("No threads yet"): * The side panel's thread picker scoped itself to `namespace:{NavigationService.CurrentNamespace}/_Thread`. CurrentNamespace is the PAGE's node path (LayoutArea stamps the top area's Address), and a thread is created under whatever node it was started from — so on every page that had never hosted a thread of its own, the picker queried a namespace holding nothing. * The in-thread nav menu asked the server for every thread and then kept the ones where `n.CreatedBy == me`. Threads live in the _Thread satellite table, whose reads project NULL::text for the authorship columns (PostgreSqlStorageAdapter.AuthorCols), so MeshNode.CreatedBy is null on every thread that arrives and the predicate was false for every row, for every user. Both now go through ThreadQueries — one place holding the two rules that are invisible at the call site: ownership is decided by the query (content.createdBy, matching the dashboard query CrossPartitionThreadQueryTests already pins), and a thread list is never scoped to the page you happen to be on. ThreadListQueryTests pins all of it against a real PG-backed mesh, including the trap that only reproduces there: the row arrives with no envelope authorship at all, so re-filtering it in the client drops everything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KmBFaHTqhy7h742wkAaJKj

Copilot

Pull request overview

Fixes empty thread lists in the Blazor chat UI by centralizing and correcting the thread query strings used by the side-panel picker and in-thread navigation, and adds PostgreSQL-backed tests to prevent regressions specific to satellite-table projection behavior.

Changes:

Introduce ThreadQueries as the single source of truth for “my threads”, “my open threads”, and “threads under” query strings.
Update ThreadChatView to use the new centralized queries (removing incorrect namespace scoping and client-side filtering on MeshNode.CreatedBy).
Add new PG integration tests that pin the corrected behavior, and add a What’s New entry documenting the fix.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
test/MeshWeaver.Hosting.PostgreSql.Test/ThreadListQueryTests.cs	Adds real Postgres-backed regression tests for thread list queries, including the satellite-table `CreatedBy` projection pitfall.
src/MeshWeaver.AI/ThreadQueries.cs	Centralizes thread list query construction to prevent future call-site drift and repeats of the same failure modes.
src/MeshWeaver.Blazor.Portal/Chat/ThreadChatView.razor.cs	Switches the chat UI’s thread picker/nav menu/sub-thread list to the centralized queries; removes faulty page scoping and envelope-based client filtering.
src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-16-your-threads-list-again.md	Documents the user-visible fix in What’s New.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

github-actions · 2026-08-16T09:16:13Z