Repository navigation
Conversation
The sidebar and navigation rail reset the workspace stack with a state-callback dispatch from the root layout. That dispatch goes to the focused navigator, so with the New thread flow open the reset reached its nested stack, which has no Home or Thread route, and was dropped. Address the root stack by its key instead.
github-actions
Bot
added
vouch:trusted
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a narrowly scoped Android navigation bug fix that changes reset targeting only when a nested New thread flow has focus, while preserving the existing workspace route calculation. No product defaults, static-analysis suppressions, sensitive packages, schema changes, or deployment behavior are involved. You can add or adjust custom eligibility rules. Learn more. |
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Linked Issues check |  |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
| Title check | |
The title clearly and concisely describes the Android sidebar behavior fixed by the pull request. |
| Description check | |
The description covers the problem, fix, focused scope justification, detailed verification results, before-and-after evidence, and agent attribution. |
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
|
Note 🤖 Claude Opus 5.5 responding on behalf of Theo Closing: #21071 shipped the same fix. #21071 also fixes one more case. When the caller is the navigation container, its |
2 participants
Problem
On an unfolded Android foldable, tapping a thread in the sidebar does nothing while the New thread flow (Choose project or the draft) is open. The rail's Chats/PRs tabs have the same problem: the list switches but the detail pane stays on New thread. Dev builds log
The action 'RESET' … was not handled by any navigator.The sidebar and rail live in the root stack's layout and reset the workspace with
navigation.dispatch((state) => CommonActions.reset(…)). From there, a state-callback dispatch goes to the focused navigator. With New thread open, that is the nestedNewTaskSheetstack, whose routes areNewTask,NewTaskDraft, and so on. The reset to[Home, Thread]doesn't fit that stack, so it is dropped.Fix
resetAndroidWorkspacewalks up to the root navigator and dispatches the reset withtargetset to the root state's key.useAndroidWorkspaceSelection(sidebar threads, PR list and PR thread links) and the rail's tab selection use it. Screens on the root stack already dispatched to the root; addressing it by key doesn't change their behavior.Why this qualifies as a small focused fix
It's one defect, a reset addressed to whichever navigator happens to have focus, fixed at the two places that dispatch it from the root layout. Phone layouts don't show the sidebar or rail next to New thread, so only split view changes.
Verification
On the Android 15 Pixel 9 Pro Fold emulator (unfolded, split view), against an isolated server with the showcase Moonbase fixtures:
RESETis unhandled; after, the thread opens.RESETunhandled); after, the PR detail placeholder shows. Tapping Chats returns to Threads.main, tapping a sidebar thread with New thread open logged the same unhandledRESET; with this branch loaded, the thread opens.vp run typecheckinapps/mobilepasses;vp lintandvp fmton the changed files are clean.Before / After
Same emulator, state, and steps: open New thread, pick React, then tap two sidebar threads.
Model: Claude Opus 5.5 | Harness: Claude Code in T3 Code