[dominikzabcik]

Problem

Opening a thread from a draft or home changes openPullRequestsInRightPanel on every memoized sidebar row, even though that value is only used when clicking a PR badge. The unnecessary renders grow with the visible thread list.

Change

Read the current route through a stable callback when a PR badge is clicked. The existing route resolver still determines whether to open the PR in the right panel. Web and desktop share this sidebar; mobile uses a separate implementation. No contracts or provider behavior change.

Scope and approval

This is a small, focused performance fix for an obvious memoization defect under CONTRIBUTING.md's exception. It preserves product behavior. The independent onSnooze identity fix is already in #29150 and is not included here.

Verification

Added app-open-thread-from-draft to the existing whole-app render harness. On the base commit b8c2cfad6b, it fails with expected 4 to be 1; with this change it passes with exactly 1 SidebarThreadRow render. app-switch-thread still passes with exactly 2 row renders per switch.

Focused command (from apps/web, with T3CODE_RENDER_REPORT_DIR set to a temporary directory):

vp test run --project renders test/appScenarios.renders.tsx -t 'app-open-thread-from-draft|app-switch-thread'

vp run check:changed passes: format, lint, knip, affected-package typecheck, React Compiler checks, and all 134 tests in the six adjacent test files, including Chromium browser tests.

Manually exercised draft-to-thread navigation in the built-in Browser against this worktree's isolated development state. These captures use a public test project filter; they show the same visible result before and after. The render-count test above is the performance regression proof, not the recordings.

Measured before the test existed, with a React DevTools commit hook in a dev build (Chromium, 189 threads seeded from real data, Settled expanded to 166 rows): the draft-to-thread commit went from 248 ms with all 167 rows re-rendering to 83 ms with only the newly active row changing props. Dev React is several times slower than production, so read these as relative. No production timing benchmark or native desktop/mobile run was performed.

Before	After

Navigation recordings: before, after.

Created with Claude Opus 5.5 in Claude Code and GPT-6.1 Sol in Codex, through T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at baea1e1

Macroscope's review found this PR approvable — This change reduces sidebar row rerenders by stabilizing callbacks and reading route state when a pull-request link is clicked. Existing navigation behavior and rename authorization safeguards remain unchanged.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Sidebar rows now read whether the current route is a thread when a pull request is clicked, instead of receiving a render-time boolean. Render scenarios add shared thread navigation and coverage for navigating from a project draft to a thread.

Changes: Sidebar pull-request route behavior

Layer / File(s)	Summary
Read route state when opening pull requests apps/web/src/components/Sidebar.tsx, apps/web/src/components/sidebar/SidebarThreadRow.tsx	Sidebar passes a stable callback that reads the current route to each sortable thread row. The row reads the value when a pull-request click is handled. An explicit target URL still opens in the right panel. The thread-rename starter also uses a stable callback.
Exercise draft-to-thread navigation apps/web/test/appScenarios.renders.tsx	A shared helper navigates to a thread and waits for its last answer. The thread-switch scenario uses the helper, and a new scenario navigates from a project draft to thread A and checks the sidebar-row render count.

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

Change: Bug fix

Suggested reviewers: t3dotgg, juliusmarminge

Merge Risk: Minimal · up to baea1

This change reduces unnecessary sidebar row rerenders when navigating from a draft to a thread. Pull-request badge routing keeps its prior behavior. No concrete merge-blocking risk was found.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: opening a thread from a draft now re-renders only its sidebar row. It matches the summary (stable callback for the PR badge route check, plus the rename handler wrappe…
Description check		The description follows the template. It states the problem, the change, the scope and approval reasoning, and detailed verification with the focused command, before/after render counts, and evidence …
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.

Full details: Title check

Explanation

The title names the main change: opening a thread from a draft now re-renders only its sidebar row. It matches the summary (stable callback for the PR badge route check, plus the rename handler wrapped in useStableCallback) and the stated performance goal. It follows the conventional commit form and is concise.

Full details: Description check

Explanation

The description follows the template. It states the problem, the change, the scope and approval reasoning, and detailed verification with the focused command, before/after render counts, and evidence links. It names the models used. It has no empty required section. Some verification claims rely on external links and a manual measurement that is labeled as relative, which is acceptable. The Scope section cites CONTRIBUTING.md's exception and references #29150 without a linked issue for the bug itself, but it gives a reason for having no issue.

Finishing Touches

Generate unit tests (beta)

• 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: main
• File: .coderabbit.config.ts
• Commit: 0d585f7
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: a4de117c-5348-4c35-ad14-18cd79d6206d

Commits

Reviewing files that changed from the base of the PR and between 19004f4 and baea1e1.

Files selected for processing: 2

• apps/web/src/components/Sidebar.tsx
• apps/web/src/components/sidebar/SidebarThreadRow.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.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified the unchanged head 19004f4ec5c24742c87257d0f1bdba521e0c7231 on a linux boat vm using the real dev web app, repository playwright, and /usr/bin/google-chrome.

i first ran github/main (f12bb6229c) in a separate worktree. through the app i added the real git checkout as a project, created two conversations, and completed real codex gpt-6.1-sol turns. i preserved that app-created data for the head run, stopped main before starting the head, and completed another real codex turn on the head. no mocks or seeded fixtures were used.

the react devtools commit hook observed the actual sidebar during clicks in the running app:

main, draft -> alpha: alpha 1, beta 1, other visible thread 1
head, draft -> alpha: alpha 2, all other visible threads 0
head, alpha/beta switch: alpha 1, beta 1
head, real codex response: PR head real provider confirmed.

the live dev run confirms removal of renders in unrelated rows. the selected row rendered twice in that capture; the focused existing render harness separately passes its exactly-one-row-render assertion.

nearby behavior passed: returning to the unsent draft preserves its text; normal thread switching shows the correct conversation; the linked pr badge opens the standalone pr page from a draft/home route; clicking the same badge from another thread activates the linked thread and opens its pr in the right panel. the panel loaded this pr's real description and checks.

blacksmith verification passed:

vp run check:changed HEAD^
  format, lint, both knip passes, affected typechecks,
  134 adjacent tests, react compiler checks: pass

app-open-thread-from-draft: pass
app-switch-thread: pass

main, after opening the real conversation:

head, the same conversation and preserved draft:

head, real codex reply and linked pr opened in the thread's right panel:

Not verified

native electron, ios, and android clients; remote/relay/tunnel connections; other providers; production wall-clock performance or very large sidebar lists. web and desktop share the changed sidebar implementation, while mobile uses separate code. screenshots establish the visible state; the live commit-hook counts and existing render assertions establish the render behavior.

no code changes were needed.

Dismissing prior approval to re-evaluate baea1e1

[juliusmarminge]

Evidence

Environment on both sides: real web client, Chromium 156 on Linux, 1440×1100, light theme, fresh isolated databases, identical synthetic replay data. The overlay counts committed renders of the memoized SidebarThreadRow, skipping reused subtrees.

Steps: seed nine threads in demo-project; open Demo thread 1; click Demo thread 3; create a new draft and type 'unsent draft text'; reset the probe; click Demo thread 5; observe for 1.5 seconds.

Proven: the scenario fails on base and passes on head. Base rendered all nine memoized rows twice. The eight unrelated rows changed openPullRequestsInRightPanel and onStartRename. Head rendered only Demo thread 5 twice; all eight unrelated rows remained at zero.

Evidence	Before — 0d585f7710	After — baea1e115e
Unsent draft
Render counts
Recording	Before video	After video

Scenario source

Counts cover the measured navigation window and the memoized rows; drag-and-drop wrappers can still render.

Not shown:

• PR badge navigation was not exercised because the synthetic threads have no linked PRs.
• Home-to-thread navigation, the repeated draft-to-Demo-thread-7 sequence, and larger-list scaling were not captured; this proof covers the nine-row draft-to-Demo-thread-5 case.
• Elapsed-time improvement was not benchmarked; the evidence establishes which memoized rows render.