[juliusmarminge]

t3_thread_list's item status and its statuses filter both used activityRunStatus ?? status. activityRunStatus is null once the turn ends, so a thread held open by awaited background work (which the sidebar shows under Working as 'Waiting' and auto-settle treats as busy) was reported as 'completed' and left out of live-status filters. A new helper, listedThreadStatus, in OrchestratorMcpService.ts returns activityRunStatus when set; otherwise it returns 'waiting' when backgroundWorkHoldsCompletion(pendingBackgroundTasks) is true (the same shared predicate the sidebar, auto-settle and client-runtime use), and falls back to shell.status. The list item and the filter both use it, so they always agree. 'waiting' is already a valid OrchestratorMcpThreadStatus (an OrchestrationV2RunStatus), so the contract is unchanged. The repro test's fixture also failed typecheck: the schema allows only the literal true for awaited, so the fixture now uses awaited: true as const. The test's behavior is unchanged. No new regex or parser.

Fixes #34668

Reproduction on main

Commit 6a03ef6 (origin/main). Started a dev server on a fresh database with T3CODE_DEV_SEED=0 vp run dev and paired the web client in the preview browser. In project 'server' I started a Claude Haiku thread and asked it to run sleep 900 with Bash run_in_background, call t3_background_wait on that task id, and end its turn. It did, and the sidebar showed the thread under 'Working 1' with a 'Waiting' pill. From a second Claude Haiku thread I called t3_thread_list twice. With statuses [preparing, queued, starting, running, waiting] it returned only the calling thread (total 1). With no filter it returned the calling thread as running and 'Background Task Wait Workflow' as completed (total 2). A screenshot taken right after shows the sidebar still listing that thread under Working as 'Waiting'. A unit test in OrchestratorMcpService.test.ts ('thread list' describe) also shows the filter skipping a shell with activityRunStatus null and an awaited pending command.

Evidence

Evidence for #34668: on each commit, start a background sleep 900, register it with t3_background_wait, and end the turn. From a second thread, call t3_thread_list with live statuses, then without filtering. Both sides use fresh synthetic databases, Chromium web, 1280×800, and light theme. Model labels are redacted.

Before	After
6a03ef6568	05087f3638
Before recording	After recording

The audit's live query returns only its calling thread on base; head also includes the waiting background thread. Independent calls after the audit ends confirm zero live threads on base versus the waiting background thread on head.

Executed MCP driver · Direct MCP results · Full reproduction procedure

AI-assisted; verified with the tests and tools listed above.

Tests

Ran vp test run src/mcp/OrchestratorMcpService.test.ts -t "thread list" without the fix: 1 failed (the repro test), 2 passed. Ran vp test run src/mcp/OrchestratorMcpService.test.ts with the fix: 68/68 passed. vp run typecheck in apps/server failed on the repro fixture's awaited: true widening to boolean (TS2322) until the as const fix. Final vp run check:changed: format, lint, knip, graphql, typecheck (3 packages) and tests (3 files, 76 tests) all pass; exit 0.

Not in this change

• t3_thread_read derives its status from the runs (active/latest run status), not from shell.pendingBackgroundTasks, so it still shows neither the 'waiting' status nor the pending work; open PR fix(server): agents can see a thread's pending background work #33858 adds read-only background-work fields there.
• The list item still has no field naming the pending background tasks themselves; only its status reflects them.

AI-assisted; verified with the tests and tools listed above.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	21.5 KiB	21.5 KiB	0 B (0.0%)	24.4 KiB	✅
Codex	Live turn messages	1	1	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.9 KiB	21.9 KiB	0 B (0.0%)	24.4 KiB	✅
Claude	Live turn messages	1	1	0 (0.0%)	8	✅

Baseline: 6b1d9d5 · PR result: 05087f3 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at 05087f3

Macroscope's review found this PR approvable — Thread listing now reports threads with completion-blocking background work as waiting, consistently in results and status filters. The change preserves active-run precedence and does not alter thread execution or stored data.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Thread list items and status filters now report waiting when pending background tasks hold completion and no activity-run status is present. Activity-run status takes precedence. A test covers a thread with an awaited background command.

Changes: Thread list status

Layer / File(s)	Summary
Derive and apply listed status apps/server/src/mcp/OrchestratorMcpService.ts, apps/server/src/mcp/OrchestratorMcpService.test.ts	The thread list derives waiting when pending background tasks hold completion and no activity-run status is present. List items and status filters use this derived status. A test checks that the thread appears for live-status filters.

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Bug fix · Severity of issue fixed: Low

Possibly related PRs

• pingdotgg/t3code#24610: Adds the awaited-task contract and completion rule used by this change.

Suggested labels: bugfix, size:S

Suggested reviewers: macroscopeapp, t3dotgg

Merge Risk: Minimal · up to 05087

Thread list results and status filters now report threads with awaited background work as waiting, which matches the sidebar. No merge-blocking risk was identified.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: t3_thread_list now counts threads waiting on background work as live. It uses the conventional commit format and matches the listed status-derivation change in Orchest…
Linked Issues check		Issue #34668 requires that threads holding awaited background work count as live in t3_thread_list. Its expected outcome is that the thread appears among live statuses, or that the list item shows the…
Out of Scope Changes check		The whole-PR diff against merge base 6a03ef6 touches two files. OrchestratorMcpService.ts changes only the list item status, the statuses filter, and one new import and helper that feed them. Orche…
Description check		The description follows the repository template in substance. It has a clear problem statement (threads held open by awaited background work were reported as 'completed' and omitted from live-status f…

Full details: Title check

Explanation

The title names the main change: t3_thread_list now counts threads waiting on background work as live. It uses the conventional commit format and matches the listed status-derivation change in OrchestratorMcpService.ts and its filter. The title is specific and accurate.

Full details: Linked Issues check

Explanation

Issue #34668 requires that threads holding awaited background work count as live in t3_thread_list. Its expected outcome is that the thread appears among live statuses, or that the list item shows the pending work. The diff in apps/server/src/mcp/OrchestratorMcpService.ts adds listedThreadStatus. It returns activityRunStatus when set. Otherwise it returns 'waiting' when backgroundWorkHoldsCompletion(pendingBackgroundTasks) is true, and falls back to shell.status. listItemFromShell (list item status) and the statuses filter in listThreads both call this helper, so the item status and the filter agree. The helper uses the same shared predicate that the issue cites for auto-settle and the sidebar. A new test in OrchestratorMcpService.test.ts ('thread list') asserts that a null-activity thread with an awaited pending command is returned by the live-status filter. The issue names mapping to 'waiting' as an acceptable fix. Not required by the issue's expected outcome: t3_thread_read still lacks pending-work fields. The PR excludes this and cites PR #33858. The evidence section of the PR description is pending. This is not a coding requirement. Test and typecheck results in the PR description were not re-run in this review.

Full details: Out of Scope Changes check

Explanation

The whole-PR diff against merge base 6a03ef6 touches two files. OrchestratorMcpService.ts changes only the list item status, the statuses filter, and one new import and helper that feed them. OrchestratorMcpService.test.ts adds one fixture thread and one test for the same filter, plus the 'as const' literal fix for the fixture's awaited field. No unrelated code, t3_thread_read logic, or contract changes appear in the diff. Every hunk relates to the issue's list status behavior.

Full details: Description check

Explanation

The description follows the repository template in substance. It has a clear problem statement (threads held open by awaited background work were reported as 'completed' and omitted from live-status filters), a concrete change (new listedThreadStatus helper used by both the list item and the filter), a linked issue (#34668), and verification. Verification includes a reproduction on main, before/after evidence, and test and check runs with results. Gaps: the 'Scope and approval' section does not explicitly state maintainer approval or explain why the fix qualifies without a prior issue. It links the issue but does not show a triaged issue or approval comment. The template's required approval section is therefore only partly satisfied. The PR body also does not use the template's exact section headings (it uses an unlabeled problem/change narrative plus 'Reproduction on main', 'Evidence', 'Tests', and 'Not in this change'). The core content is present, so the check passes, but the approval link should be added or the exemption explained.

Finishing Touches

Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: factory/issue-34668
• File: .coderabbit.config.ts
• Commit: 05087f3
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Team
• Run ID: 90f41857-d669-4598-b6b1-3d13e37093f5

Commits

Reviewing files that changed from the base of the PR and between cf906e1 and 05087f3.

Files selected for processing: 2

• apps/server/src/mcp/OrchestratorMcpService.test.ts
• apps/server/src/mcp/OrchestratorMcpService.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 4 remain after this review.