Fix diff button when Show code review button toggle is off by anshul-garg27 · Pull Request #9600 · warpdotdev/warp

anshul-garg27 · 2026-04-30T14:03:45Z

Closes #9196.

Description

Two show_code_review_button gates were dropping panel-open requests on the floor when the user had hidden the toolbar button:

1. Data-path gate at Workspace::setup_code_review_panel (view.rs:7982)

if !*TabSettings::as_ref(ctx).show_code_review_button {
    return;
}

update_right_panel_open_state calls into this whenever the right panel is being opened (chip click, Shift+Cmd+= keybinding, etc.), so the early return silently swallowed every explicit user action.

2. Render-path gate at Workspace::render_config_panel and render_config_panel_maximized (view.rs:18981 / 19040)

if !item.is_available(app) || !item.is_panel() { return None; }
…
if !HeaderToolbarItemKind::CodeReview.is_available(app) { return None; }

HeaderToolbarItemKind::is_available for CodeReview returns *TabSettings::as_ref(app).show_code_review_button.value() (header_toolbar_item.rs:89). So even after fix #1 set pane_group.right_panel_open = true and setup_code_review_panel ran, the next render frame saw is_available() == false and returned None — the right_panel_view was never added to the layout.

This second gate is what @moirahuang flagged when their local repro still showed nothing happening after the first fix landed. The data was correct; the panel was just never composed into the UI.

Fix

Drop the early return at setup_code_review_panel. The setting is meant to gate only the toolbar button's visibility (already enforced correctly by header_toolbar_item.rs::is_available, which feeds render_header_toolbar_button at view.rs:17276).
Switch panel-render call sites from is_available → is_supported. is_available's own doc-comment says it's specifically "Whether this item should be shown in the toolbar — checks both is_supported and user show/hide preferences." Using it to gate panel rendering conflates two unrelated concerns. Panel rendering should only care about whether the feature is compiled in (is_supported), not whether the user has hidden the toolbar button.

For CodeReview, is_supported is cfg!(feature = "local_fs"). For the other variants in the same match (TabsPanel, ToolsPanel), is_available already equals is_supported (default _ => true arm in the inner match), so behaviour is unchanged. AgentManagement and NotificationsMailbox return None unconditionally inside render_config_panel, so the change is moot for them too.

Caller audit for `setup_code_review_panel`

5 call sites in view.rs:

view.rs:3681 — TransferredTab flow, only runs when the source tab already had right_panel_open == true.
view.rs:8136 — update_right_panel_open_state with should_open == true. The diff-button path that terminal prompt: diff button no longer working when code review tool is disabled #9196 is about.
view.rs:13372 — PaneFocused event, gated on right_panel_open already true.
view.rs:13490 — RepoChanged event, gated on right_panel_open already true.
view.rs:14458 — session env update, gated on right_panel_open already true.

None of these need the show_code_review_button gate — they're either explicit user actions or gated on right_panel_open already being open. The toolbar button toggle continues to do its job at render_header_toolbar_button independently.

Testing

Reproduced @moirahuang's test locally on macOS 26.4.1 (Apple Silicon) against WarpOss.app built from this branch:

Settings → "Show code review button" → OFF
echo "x" >> README.md inside a git repo
Click the diff stats chip on the prompt (+1 -0)

Result: Code review panel opens on the right showing the diff, while the toolbar button stays hidden — exactly the expected behaviour from issue #9196. Inverse case (toggle ON) also verified: toolbar button visible, panel still works the same.

cargo fmt -p warp -- --check passes.
cargo nextest skipped locally — Metal toolchain unavailable on my machine, mirroring Expand ~ in warp://action/new_tab?path= URLs #9277. CI will exercise the change.

Server API

No server changes.

Agent Mode

Not applicable.

Changelog Entries

CHANGELOG-BUG-FIX: The diff button on the terminal prompt now opens the code review panel even when the toolbar's "Show code review button" toggle is disabled (regression from a recent release).

oz-for-oss · 2026-04-30T14:03:59Z

@anshul-garg27

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @vorporeal.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss

Overview

This PR removes the show_code_review_button guard from Workspace::setup_code_review_panel, keeping the setting scoped to toolbar button visibility while allowing explicit panel-open paths such as git-diff block actions to initialize the code review panel.

Concerns

No blocking correctness, security, error-handling, or performance concerns found in the changed diff lines.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

vorporeal · 2026-04-30T16:53:49Z

reassigning to @moirahuang, based on some historical git blame information

moirahuang · 2026-04-30T18:12:38Z

-        if !*TabSettings::as_ref(ctx).show_code_review_button {
-            return;
-        }
+        // Note: do NOT gate this on `show_code_review_button` — that setting


nit: i think we don't need this comment! although this is helpful context for this PR, i think we don't need a comment explaining why code is not there

moirahuang · 2026-04-30T18:21:09Z

I just tested this locally and I'm not seeing the panel open w the setting off, mind locally confirming your change please?

anshul-garg27 · 2026-05-01T00:31:23Z

@moirahuang Good catch — you were right, the original fix was incomplete. Pushed 19cf7ba which adds the missing piece.

What was wrong

The original commit removed the show_code_review_button early-return from setup_code_review_panel (the data path), but a second gate was still active in the render path at Workspace::render_config_panel (view.rs:18981) and render_config_panel_maximized (view.rs:19030). Both were calling item.is_available(app), which for HeaderToolbarItemKind::CodeReview returns *TabSettings::as_ref(app).show_code_review_button.value() (header_toolbar_item.rs:89).

Net effect:

chip click → open_right_panel → update_right_panel_open_state set pane_group.right_panel_open = true ✅
setup_code_review_panel ran without bailing out ✅ (original fix worked)
but on the next render frame, render_config_panel saw is_available() return false because the toggle was off, returned None, so right_panel_view was never added to the layout — the panel stayed invisible. ❌

That matches your repro exactly.

The fix

is_available() doc-comment specifically says "Whether this item should be shown in the toolbar — checks both is_supported and user show/hide preferences." Using it for panel rendering bundles two unrelated concerns: "is the feature compiled in" vs "does the user want the toolbar button visible." For the panel layer we only care about the former, so I switched both call sites to is_supported(app).

is_supported() for CodeReview is just cfg!(feature = "local_fs") — a compile-time gate that's already enforced everywhere panel rendering touches.

This is safe for the other variants in the match: TabsPanel and ToolsPanel already returned is_supported && true from is_available (the default _ => true arm), and AgentManagement/NotificationsMailbox return None unconditionally inside the match.

Verified locally

Built WarpOss.app with the fix on macOS 26.4.1 (Apple Silicon). Repro your test:

Settings → Show code review button → OFF
echo "x" >> README.md in a git repo
Click the diff chip on the prompt (+1 -0)

Result: code review panel opens on the right with the diff visible, while the toolbar button stays hidden — exactly what #9196 reports as the expected behaviour. Toolbar button gating is preserved (render_header_toolbar_button still uses is_available at view.rs:17276, which is correct for that path).

Format check passes. cargo nextest skipped locally (Metal toolchain unavailable, same as #9277). Ready for re-review.

moirahuang

thanks for updating the PR! please address the comments and add some unit tests and then i'll approve!

moirahuang · 2026-05-01T16:23:51Z

+    /// Returns `None` if the panel should not be rendered (item not supported,
    /// panel not open, or item is not a panel type).
+    ///
+    /// Uses `is_supported` instead of `is_available` because user show/hide


similar comment as here, i think we don't need this comment. it makes sense in the context of this PR but it's not needed in the actual code

moirahuang · 2026-05-01T16:24:06Z

    }

    /// Renders the maximized code review panel if it is configured and maximized.
+    /// Uses `is_supported` instead of `is_available` for the same reason as


similar request here that we don't need this comment

moirahuang · 2026-05-01T16:32:15Z

i just realized there's one more edge case i think we should handle. if we remove the code review panel from the toolbar, we should handle still showing the code review panel

anshul-garg27 · 2026-05-03T20:52:56Z

@moirahuang Pushed a75e74e addressing all three points from your review.

1. Removed the three explanatory comments

view.rs:7985, view.rs:18982, view.rs:19031 — all three "why this gate isn't here" comments are gone.

2. Toolbar-removed edge case

You're right — config.left_items() and config.right_items() skip Code Review entirely when the user has removed it from the toolbar layout, so the panel never renders even with right_panel_open == true.

Added a fallback after the right-side iteration in both render paths (horizontal-tabs at view.rs:18277 and vertical-tabs at view.rs:18923):

} else if !config.contains_item(&HeaderToolbarItemKind::CodeReview) {
    Self::add_panel_with_separator(
        &mut main_content,
        &mut prev_panel_added,
        self.render_config_panel(&HeaderToolbarItemKind::CodeReview, …),
        app,
    );
}

The fallback is gated on the same is_supported(app) + right_panel_open checks already in render_config_panel, so it stays a no-op when the panel is closed or the feature isn't compiled in. The maximized branch already handled this case independently via render_config_panel_maximized, so the new fallback only runs for the non-maximized path.

To support that without scattering the left.contains() || right.contains() pattern, added HeaderToolbarChipSelection::contains_item in tab_settings.rs.

3. Unit tests

Four new tests in tab_settings_tests.rs:

header_toolbar_chip_selection_default_contains_code_review — sanity: the default layout has Code Review on the right.
header_toolbar_chip_selection_custom_without_code_review_reports_absent — models the exact scenario you flagged: user removes Code Review from both sides; contains_item returns false so the fallback render kicks in.
header_toolbar_chip_selection_custom_with_code_review_on_left_reports_present — verifies side-insensitivity (moving the item from right to left still keeps it in config).
header_toolbar_chip_selection_custom_empty_reports_all_absent — covers the degenerate empty-layout case across all toolbar items.

Local verification

cargo fmt -p warp -- --check passes.
cargo check --features=gui --tests -p warp passes (3m 18s) — confirms my changes compile cleanly in the test profile.
cargo nextest for the warp crate is currently broken on upstream/master for unrelated reasons (warp_graphql cynic+serde deserialization errors and http_client calling a renamed reqwest API tls_built_in_webpki_certs that's now tls_built_in_root_certs). Same errors reproduce on a clean upstream/master checkout without any of my changes, so they're pre-existing. Trusting CI to exercise the test suite end-to-end.

Branch rebased onto 525dfb6.

Closes warpdotdev#9196. The `show_code_review_button` setting is meant to gate only the toolbar button's visibility — but two unrelated places in the workspace also short-circuited on it, so explicit user actions like clicking the diff chip on the prompt or hitting the toggle keybinding silently did nothing whenever the user had hidden the toolbar button. This PR removes both gates and adds a render fallback for the case where the user has removed the Code Review item from the toolbar layout entirely. Three changes in `app/src/workspace/view.rs`, one helper in `app/src/workspace/tab_settings.rs`, and four unit tests in `app/src/workspace/tab_settings_tests.rs`. 1. **Data path** — `Workspace::setup_code_review_panel` no longer bails out on `!show_code_review_button`. The setting controls toolbar button visibility, which is already enforced correctly by `header_toolbar_item.rs::is_available` (driving `render_header_toolbar_button`); the panel infrastructure must not disappear when the user just hides the button. 2. **Render path** — `render_config_panel` and `render_config_panel_maximized` previously gated on `is_available()`, which for `CodeReview` includes the same `show_code_review_button` user preference. Both call sites switch to `is_supported(app)` (compile-time `cfg!(feature = "local_fs")`). `is_available`'s own doc-comment scopes it to "should be shown in the toolbar" — using it for panel rendering conflated two unrelated concerns. `TabsPanel`/`ToolsPanel` are unaffected because their `is_available` already equals `is_supported`, and `AgentManagement`/`NotificationsMailbox` return `None` unconditionally inside `render_config_panel`. 3. **Toolbar-removed fallback** — when the user removes the Code Review item from the toolbar via the toolbar editor, the `config.left_items()` / `config.right_items()` iterations skip it entirely, so the panel could never render even with the data path open. After the right-side iteration in both the horizontal and vertical-tabs render paths, fall back to rendering the Code Review panel directly when the item isn't part of the layout. The fallback is gated on the same `is_supported` + `right_panel_open` checks inside `render_config_panel`, so it's a no-op when the panel is closed or the feature isn't compiled in. Adds `HeaderToolbarChipSelection::contains_item` for the fallback check, with four unit tests covering Default and Custom variants (present, absent, side-insensitive, empty).

moirahuang

looks good to me! thanks for making this PR

@moirahuang

…v#9600) Closes warpdotdev#9196. ### Description Two `show_code_review_button` gates were dropping panel-open requests on the floor when the user had hidden the toolbar button: **1. Data-path gate at `Workspace::setup_code_review_panel` (`view.rs:7982`)** ```rust if !*TabSettings::as_ref(ctx).show_code_review_button { return; } ``` `update_right_panel_open_state` calls into this whenever the right panel is being opened (chip click, `Shift+Cmd+=` keybinding, etc.), so the early return silently swallowed every explicit user action. **2. Render-path gate at `Workspace::render_config_panel` and `render_config_panel_maximized` (`view.rs:18981` / `19040`)** ```rust if !item.is_available(app) || !item.is_panel() { return None; } … if !HeaderToolbarItemKind::CodeReview.is_available(app) { return None; } ``` `HeaderToolbarItemKind::is_available` for `CodeReview` returns `*TabSettings::as_ref(app).show_code_review_button.value()` (`header_toolbar_item.rs:89`). So even after fix #1 set `pane_group.right_panel_open = true` and `setup_code_review_panel` ran, the next render frame saw `is_available() == false` and returned `None` — the `right_panel_view` was never added to the layout. This second gate is what @moirahuang flagged when their local repro still showed nothing happening after the first fix landed. The data was correct; the panel was just never composed into the UI. ### Fix 1. **Drop the early return at `setup_code_review_panel`.** The setting is meant to gate only the toolbar button's visibility (already enforced correctly by `header_toolbar_item.rs::is_available`, which feeds `render_header_toolbar_button` at `view.rs:17276`). 2. **Switch panel-render call sites from `is_available` → `is_supported`.** `is_available`'s own doc-comment says it's specifically *"Whether this item should be shown in the **toolbar** — checks both `is_supported` and user show/hide preferences."* Using it to gate panel rendering conflates two unrelated concerns. Panel rendering should only care about whether the feature is compiled in (`is_supported`), not whether the user has hidden the toolbar button. For `CodeReview`, `is_supported` is `cfg!(feature = "local_fs")`. For the other variants in the same match (`TabsPanel`, `ToolsPanel`), `is_available` already equals `is_supported` (default `_ => true` arm in the inner match), so behaviour is unchanged. `AgentManagement` and `NotificationsMailbox` return `None` unconditionally inside `render_config_panel`, so the change is moot for them too. ### Caller audit for `setup_code_review_panel` 5 call sites in `view.rs`: 1. `view.rs:3681` — `TransferredTab` flow, only runs when the source tab already had `right_panel_open == true`. 2. `view.rs:8136` — `update_right_panel_open_state` with `should_open == true`. **The diff-button path** that warpdotdev#9196 is about. 3. `view.rs:13372` — `PaneFocused` event, gated on `right_panel_open` already true. 4. `view.rs:13490` — `RepoChanged` event, gated on `right_panel_open` already true. 5. `view.rs:14458` — session env update, gated on `right_panel_open` already true. None of these need the `show_code_review_button` gate — they're either explicit user actions or gated on `right_panel_open` already being open. The toolbar button toggle continues to do its job at `render_header_toolbar_button` independently. ### Testing Reproduced @moirahuang's test locally on macOS 26.4.1 (Apple Silicon) against `WarpOss.app` built from this branch: 1. Settings → "Show code review button" → **OFF** 2. `echo "x" >> README.md` inside a git repo 3. Click the diff stats chip on the prompt (`+1 -0`) **Result:** Code review panel opens on the right showing the diff, while the toolbar button stays hidden — exactly the expected behaviour from issue warpdotdev#9196. Inverse case (toggle ON) also verified: toolbar button visible, panel still works the same. - `cargo fmt -p warp -- --check` passes. - `cargo nextest` skipped locally — Metal toolchain unavailable on my machine, mirroring warpdotdev#9277. CI will exercise the change. ### Server API No server changes. ### Agent Mode Not applicable. ### Changelog Entries `CHANGELOG-BUG-FIX`: The diff button on the terminal prompt now opens the code review panel even when the toolbar's "Show code review button" toggle is disabled (regression from a recent release). Co-authored-by: anshul-garg27 <[email protected]>

@moirahuang

…v#9600) Closes warpdotdev#9196. ### Description Two `show_code_review_button` gates were dropping panel-open requests on the floor when the user had hidden the toolbar button: **1. Data-path gate at `Workspace::setup_code_review_panel` (`view.rs:7982`)** ```rust if !*TabSettings::as_ref(ctx).show_code_review_button { return; } ``` `update_right_panel_open_state` calls into this whenever the right panel is being opened (chip click, `Shift+Cmd+=` keybinding, etc.), so the early return silently swallowed every explicit user action. **2. Render-path gate at `Workspace::render_config_panel` and `render_config_panel_maximized` (`view.rs:18981` / `19040`)** ```rust if !item.is_available(app) || !item.is_panel() { return None; } … if !HeaderToolbarItemKind::CodeReview.is_available(app) { return None; } ``` `HeaderToolbarItemKind::is_available` for `CodeReview` returns `*TabSettings::as_ref(app).show_code_review_button.value()` (`header_toolbar_item.rs:89`). So even after fix warpdotdev#1 set `pane_group.right_panel_open = true` and `setup_code_review_panel` ran, the next render frame saw `is_available() == false` and returned `None` — the `right_panel_view` was never added to the layout. This second gate is what @moirahuang flagged when their local repro still showed nothing happening after the first fix landed. The data was correct; the panel was just never composed into the UI. ### Fix 1. **Drop the early return at `setup_code_review_panel`.** The setting is meant to gate only the toolbar button's visibility (already enforced correctly by `header_toolbar_item.rs::is_available`, which feeds `render_header_toolbar_button` at `view.rs:17276`). 2. **Switch panel-render call sites from `is_available` → `is_supported`.** `is_available`'s own doc-comment says it's specifically *"Whether this item should be shown in the **toolbar** — checks both `is_supported` and user show/hide preferences."* Using it to gate panel rendering conflates two unrelated concerns. Panel rendering should only care about whether the feature is compiled in (`is_supported`), not whether the user has hidden the toolbar button. For `CodeReview`, `is_supported` is `cfg!(feature = "local_fs")`. For the other variants in the same match (`TabsPanel`, `ToolsPanel`), `is_available` already equals `is_supported` (default `_ => true` arm in the inner match), so behaviour is unchanged. `AgentManagement` and `NotificationsMailbox` return `None` unconditionally inside `render_config_panel`, so the change is moot for them too. ### Caller audit for `setup_code_review_panel` 5 call sites in `view.rs`: 1. `view.rs:3681` — `TransferredTab` flow, only runs when the source tab already had `right_panel_open == true`. 2. `view.rs:8136` — `update_right_panel_open_state` with `should_open == true`. **The diff-button path** that warpdotdev#9196 is about. 3. `view.rs:13372` — `PaneFocused` event, gated on `right_panel_open` already true. 4. `view.rs:13490` — `RepoChanged` event, gated on `right_panel_open` already true. 5. `view.rs:14458` — session env update, gated on `right_panel_open` already true. None of these need the `show_code_review_button` gate — they're either explicit user actions or gated on `right_panel_open` already being open. The toolbar button toggle continues to do its job at `render_header_toolbar_button` independently. ### Testing Reproduced @moirahuang's test locally on macOS 26.4.1 (Apple Silicon) against `WarpOss.app` built from this branch: 1. Settings → "Show code review button" → **OFF** 2. `echo "x" >> README.md` inside a git repo 3. Click the diff stats chip on the prompt (`+1 -0`) **Result:** Code review panel opens on the right showing the diff, while the toolbar button stays hidden — exactly the expected behaviour from issue warpdotdev#9196. Inverse case (toggle ON) also verified: toolbar button visible, panel still works the same. - `cargo fmt -p warp -- --check` passes. - `cargo nextest` skipped locally — Metal toolchain unavailable on my machine, mirroring warpdotdev#9277. CI will exercise the change. ### Server API No server changes. ### Agent Mode Not applicable. ### Changelog Entries `CHANGELOG-BUG-FIX`: The diff button on the terminal prompt now opens the code review panel even when the toolbar's "Show code review button" toggle is disabled (regression from a recent release). Co-authored-by: anshul-garg27 <[email protected]>

Cherry-picked from upstream: - fix: highlight C++ header extensions (warpdotdev#9388) - Run executable shell scripts in the terminal (warpdotdev#9503) - Revert schema generator binary recompilation fix (warpdotdev#9676) - Remove stray backticks from Windows installer README (warpdotdev#9691) - Fix chord shortcuts on Windows non-Latin keyboard layouts (warpdotdev#9476) - Scroll output with Page Up/Down from prompt (warpdotdev#9624) - Respect Markdown Viewer setting for .md links in AI rules/facts panel (warpdotdev#9699) - fix: disable reset grid checks for restored blocks on Windows (warpdotdev#9987) - add RedirectionGuard=no to windows-installer.iss (warpdotdev#9863) - Windows quake mode window correctly sized (warpdotdev#9891) - fix: update rand to 0.9.4 (GHSA-cq8v-f236-94qc) (warpdotdev#10060) - Fix diff button when Show code review button toggle is off (warpdotdev#9600) - Fix freshly cloned repo stuck in loading state (warpdotdev#9998) - Fix terminal text selection not auto-scrolling when dragging (warpdotdev#9448) - Resolve conflict markers from 3f0ac51 and edac651

cla-bot Bot added the cla-signed label Apr 30, 2026

oz-for-oss Bot reviewed Apr 30, 2026

View reviewed changes

oz-for-oss Bot requested a review from vorporeal April 30, 2026 14:07

vorporeal requested review from lucieleblanc and moirahuang and removed request for lucieleblanc and vorporeal April 30, 2026 16:52

captainsafia added the external-contributor Indicates that a PR has been opened by someone outside the Warp team. label Apr 30, 2026 — with Warp Dev Github Integration

moirahuang reviewed Apr 30, 2026

View reviewed changes

anshul-garg27 force-pushed the fix/9196-diff-button-toolbar-gate branch from dace6dc to 19cf7ba Compare May 1, 2026 00:31

moirahuang reviewed May 1, 2026

View reviewed changes

anshul-garg27 force-pushed the fix/9196-diff-button-toolbar-gate branch from 19cf7ba to a75e74e Compare May 3, 2026 20:52

anshul-garg27 force-pushed the fix/9196-diff-button-toolbar-gate branch from a75e74e to e2808df Compare May 3, 2026 20:57

moirahuang approved these changes May 4, 2026

View reviewed changes

moirahuang merged commit a057a10 into warpdotdev:master May 4, 2026
22 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix diff button when Show code review button toggle is off#9600

Fix diff button when Show code review button toggle is off#9600
moirahuang merged 1 commit intowarpdotdev:masterfrom
anshul-garg27:fix/9196-diff-button-toolbar-gate

anshul-garg27 commented Apr 30, 2026 •

edited

Loading

Uh oh!

oz-for-oss Bot commented Apr 30, 2026 •

edited

Loading

Uh oh!

oz-for-oss Bot left a comment

Uh oh!

vorporeal commented Apr 30, 2026

Uh oh!

moirahuang Apr 30, 2026

Uh oh!

moirahuang commented Apr 30, 2026

Uh oh!

anshul-garg27 commented May 1, 2026

Uh oh!

moirahuang left a comment •

edited

Loading

Uh oh!

moirahuang May 1, 2026

Uh oh!

moirahuang May 1, 2026

Uh oh!

moirahuang commented May 1, 2026

Uh oh!

anshul-garg27 commented May 3, 2026

Uh oh!

moirahuang left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

anshul-garg27 commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Fix

Caller audit for setup_code_review_panel

Testing

Server API

Agent Mode

Changelog Entries

Uh oh!

oz-for-oss Bot commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oz-for-oss Bot left a comment

Choose a reason for hiding this comment

Overview

Concerns

Verdict

Uh oh!

vorporeal commented Apr 30, 2026

Uh oh!

moirahuang Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

moirahuang commented Apr 30, 2026

Uh oh!

anshul-garg27 commented May 1, 2026

What was wrong

The fix

Verified locally

Uh oh!

moirahuang left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

moirahuang May 1, 2026

Choose a reason for hiding this comment

Uh oh!

moirahuang May 1, 2026

Choose a reason for hiding this comment

Uh oh!

moirahuang commented May 1, 2026

Uh oh!

anshul-garg27 commented May 3, 2026

1. Removed the three explanatory comments

2. Toolbar-removed edge case

3. Unit tests

Local verification

Uh oh!

moirahuang left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

anshul-garg27 commented Apr 30, 2026 •

edited

Loading

Caller audit for `setup_code_review_panel`

oz-for-oss Bot commented Apr 30, 2026 •

edited

Loading

moirahuang left a comment •

edited

Loading