Synced from GitHub
test(web): linked-environment subagents keep opening in their own thread#26492
Problem
#28592 fixed Open question and Open approval opening a blank new thread when the subagent runs on a linked environment, but it shipped without a test, so nothing stops the bug coming back.
This PR started as a fix for the same bug. #28592 landed first, so its code is kept and only the test remains.
Change
Extends the existing useThreadLifecycle browser test, written by maria-rcks, to cover opening a child from the parent thread:
- Same environment: Open question
- Linked environment: Open question, Open approval and the child's name
Checks: vp run check:changed passes. All 9 tests in the file pass, and the 3 linked-environment cases fail when the web change from #28592 is undone.
Closes #27005, which reports this bug and was left open after #28592 merged.
The bug
Before: Open question on a subagent on a linked environment lands on a blank New thread page.
After: the same click opens the subagent's thread with the question ready to answer. Captured with this PR's original fix, which behaved the same way as #28592 in the test above.
The earlier council review covered the original fix, not this test-only diff.
Created with Claude Opus 5.5 (claude-opus-5-5) in Claude Code, running in T3 Code.
Checks
23 successful · 13 skipped
Added 1 commit
- fix(clients): Open question on a linked-environment subagent opens its threadb615419
Synced from GitHub
Approvability
Verdict: Approved at b615419
Macroscope's review found this PR approvable — Child-input actions now open the subagent thread in its own environment on web and mobile. This is a contained navigation correction that preserves existing same-environment behavior and availability safeguards.
You can add or adjust custom eligibility rules. Learn more.
Synced from GitHub
No actionable comments were generated in the recent review.
External image Recent review info
-
External image Run configuration
- Source mode: Auto
- Repository: pingdotgg/t3code
- Branch: main
- File: .coderabbit.config.ts
- Commit: edc37c9
- Layers: Repository TS config
- Review profile: CHILL
- Plan: Advanced
- Run ID:
10276542-ffae-4fa8-a532-2d9f80defa95
External image Commits
Reviewing files that changed from the base of the PR and between 720ae84e087ea49263c572c484e7804cd9189722 and 1ed113fd2fe06b6146607e908098609c1173cfb0.
External image Files selected for processing: 1
apps/web/src/components/chat/useThreadLifecycle.browser.test.tsx
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
Walkthrough
Browser tests now configure child-thread inputs and verify that question, child, and approval links navigate to the child thread in its own environment. The test harness renders the child description and actions.
Changes: Child-thread navigation tests
Layer / File(s) Summary Configure child inputs and test navigation
apps/web/src/components/chat/useThreadLifecycle.browser.test.tsxThe test mock provides configurable child inputs and resets them between tests. Parameterized cases cover local and remote child environments, optional pending approvals, and question, child, or approval links. The harness renders the child description and actions. Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Other
Possibly related issues
#29318— The tests cover remote child navigation through child and approval links.
Suggested reviewers:
batuhan1999
Merge Risk: External image Minimal · up to 1ed11
The added tests cover opening child threads in their own environment. No material merge risk was identified.
Pre-merge checks: Passed 3 · Inconclusive 1
Failed Failed checks: 1 inconclusive
Check name Status Explanation Resolution Linked Issues check Inconclusive Issue #27005requires that the child-input banner open the child thread in the child's own environment. The whole-PR diff (merge base edc37c96 to head 1ed113fd) changes only apps/web/src/components/ch…Establish whether the background-work 'Open' button navigates to the subagent thread under its own environment. Needed evidence: the onOpenThread handler supplied to backgroundWorkNowItem in useThreadLifecycle.tsx, or a test that clicks 'Op… Passed Passed checks: 3 passed
Check name Status Explanation Title check Passed The title clearly identifies the main change: adding web tests for linked-environment subagent thread navigation. It is concise and follows the repository’s conventional format. Description check Passed The description covers the problem, the test changes, linked issue, verification results, regression evidence, and UI evidence. The scope section does not include an explicit maintainer approval comme… Out of Scope Changes check Passed The whole-PR diff against the merge base changes one file: useThreadLifecycle.browser.test.tsx (+41/-1). All changes support the test coverage described for #27005. The added EnvironmentThreadShell ty…Full details: Description check
Explanation
The description covers the problem, the test changes, linked issue, verification results, regression evidence, and UI evidence. The scope section does not include an explicit maintainer approval comment, but the description is otherwise mostly complete and focused.
Full details: Out of Scope Changes check
Explanation
The whole-PR diff against the merge base changes one file: useThreadLifecycle.browser.test.tsx (+41/-1). All changes support the test coverage described for
#27005. The added EnvironmentThreadShell type import and the childThreadInputs state support the it.each cases. The reset in setup keeps state isolated between tests. The RestoreBranchHarness rendering of childInputNow.description and childInputNow.actions exposes the buttons that the test clicks. No production source, configuration, or unrelated file changed. The PR description's before/after media and the review history concern the earlier fix and do not add code changes in this diff.
Full details: Linked Issues check
Explanation
Issue
#27005requires that the child-input banner open the child thread in the child's own environment. The whole-PR diff (merge base edc37c96 to head 1ed113fd) changes only apps/web/src/components/chat/useThreadLifecycle.browser.test.tsx. The fix is therefore already present at the merge base. At head, childInputNowItem in ThreadActivityBanners.tsx passes child.environmentId and first.environmentId to onOpenThread. The new it.each test clicks 'Open question', 'Child', and 'Open approval' for local and remote children. It asserts the pathname /<childEnvironmentId>/child. This covers the reported child-input behavior. The test run results were not verified by this assessment. Issue#27005also asks the reviewer to check the background-work banner 'Open' button. In backgroundWorkNowItem, that button calls onOpenThread(onlyThreadId) with a thread id only. The PR does not change or test that path. The onOpenRelatedThread implementation in useThreadLifecycle.tsx was truncated in the read, so it is unknown whether that path resolves to the parent environment.Resolution
Establish whether the background-work 'Open' button navigates to the subagent thread under its own environment. Needed evidence: the onOpenThread handler supplied to backgroundWorkNowItem in useThreadLifecycle.tsx, or a test that clicks 'Open' for a remote background subagent and asserts the route /<childEnvironmentId>/<childThreadId>. If that path already resolves to the child's environment, no change is needed. Also confirm that the new browser test passes at head.
Finishing Touches
Generate unit tests (beta)
- Create a new PR
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Added 2 commits
Note
Written by gpt-6.1-sol on behalf of Maria
Verified in a real dev environment
verified exact head 1ed113fd2fe06b6146607e908098609c1173cfb0 on linux with the real dev web/server, playwright from the repo, and /usr/bin/google-chrome. projects, linked-environment pairing, threads, and real codex gpt-6.1-sol turns were created through the app. no mocks, replay provider, fixtures, or database injection.
tested github/main at f6503f0e717f5d577a897149b4ceeb3d1bf00b3a first in a separate worktree. the original bug no longer reproduces: #28592 already fixed it. the current pr diff is regression coverage only. the main/pr captures below use the same pending remote question.
on the pr:
- "open question" and the child-name action open the child in its linked environment with the real blue/green question visible. submitting green resumes the child, and the parent receives green.
- "open approval" opens the remote child's actual approval. approving executes
printf approval-verified, returns exit code 0, and the parent receives the result. - returning to the parent works. the local background "open" action opens its local child, and submitting blue completes that child.
blacksmith passed all 9 lifecycle browser tests and vp run check:changed edc37c96c810d42761ab510c6a3e9d0a741547dc: format, lint, knip, affected typechecks, and focused tests. 29 ci contexts were successful. no source changes were needed.
short real-provider transcript
main: linked child question already opens correctly
pr: the same linked child question opens correctly
main: open question navigates to the linked child
pr: open question navigates to the linked child
pr: open approval navigates to the linked child and approval resumes it
pr: the approved real command completed successfully
Not verified
native ios/android and the electron shell were not run on this linux vm. other providers and transport across separate machines, relay, or tunnel were not exercised. linked environments here were two isolated servers on the same vm. the remote background-work "open" action was not exercised; the question, child-name, and approval actions were.
Added 1 commit
- Merge remote-tracking branch 'origin/main' into fix/open-question-linked-environment1ed113f