feat(investigations): Open block comment threads in a drawer

[wedamija]

We're adding comments to Investigations, and this is one of a series of frontend PRs that build the feature. Comments show in an Activity section at the bottom of the page, and block comments open in a thread drawer. Everything is behind the investigations flag.

This PR adds block comment threads:

• A "Comment" item in each block's menu opens the block's thread in a side drawer.
• The thread lists comments oldest first, with a composer to reply.
• The drawer state is in the URL, so a link can open a thread and highlight a comment.
• A click outside the drawer closes it.

[github-actions]

Story previews

Preview the stories changed in this PR on the Vercel deployment:

• app/views/investigations/detail/cell.stories.tsx
• app/views/investigations/detail/index.stories.tsx

_{Preview deployment: https://sentry-h8vr28f9c.sentry.dev}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2448f65. Configure here.}

[sentry]

Sentry Snapshot Testing

Name	Added	Removed	Changed	Renamed	Unchanged	Skipped	Status
sentry-frontend sentry-frontend	0	0	0	0	630	0	✅ Unchanged

⚙️ sentry-frontend Snapshot Settings

[billyvg]

🤖 AI review by Claude, an AI agent. I'm reviewing this stack at @billyvg's request and wrote the inline comments below. @wedamija, Billy will also go through these comments and the code, so please treat this as a first pass, not a final review.

Two bugs, both small fixes:

1. The drawer shows edit/delete on archived investigations. That's the same case fixed for the Activity list in #127576.
2. While a thread is in the URL, the comments drawer re-opens over any other global drawer. I confirmed this with a throwaway test (details inline).

The rest is UX and cleanup.

[billyvg]

🤖 Bug (confirmed with a test): isDrawerOpen from useDrawer() is scoped to this call site, so it also turns false when another drawer takes over the global drawer, not only when this one closes. The thread params are still in the URL, so this effect calls openDrawer again and replaces the other drawer right away.

I checked this with a throwaway spec. It renders the detail page with ?comments=open&commentsBlock=block-1 next to a component that calls useDrawer().openDrawer(...). After opening it, only "Block comments" is on screen. Without the thread params, the other drawer opens normally.

In the app, Seer Explorer in drawer mode is one way to hit this: open a thread, then ⌘K → Ask Seer. The palette is a modal, so the outside-click handler skips it and the URL params stay.

useDroppedDataDrawer guards with isAnyDrawerOpen. That alone would stop a block's Comment action from opening the thread while Explorer is open, though. Clearing the params when this drawer is replaced may fit better: remember that it was open, and on a true → false change with the URL still saying open, call closeBlockComments() instead of reopening.

[wedamija]

Fixed, but not by clearing the URL right away — that would also close most other drawers (they close on navigation). The thread now stays closed while another drawer is open and is cleared from the URL once that drawer closes.

[billyvg]

🤖 UX: Any click outside the drawer closes it and unmounts the composer, so an unsent reply is lost. A likely case is clicking into the block to re-read a chart or select a value while writing about it. The drawer is passive, so the page stays interactive, which makes that more likely. Some options: skip the outside-click close while the composer has text, keep drafts per block outside the drawer, or drop the outside-click close and rely on Esc and the header's close button.

[wedamija]

We now save this per block, with a 7 day ttl so that we don't lose draft replies.

[github-actions]

📊 Type Coverage Diff

Metric	Before	After	Delta
Coverage	95.74%	95.74%	±0%
Typed	142,139	142,229	🟢 +90
Untyped	6,330	6,331	🔴 +1

🔍 1 new type safety issue introduced

Type assertions (as) (1 new)

File	Line	Detail
static/app/views/investigations/comments/commentDrafts.ts	14	as Drafts — JSON.parse(localStorageWrapper.getItem(STORAGE_KEY) ?? '{}') as Drafts

This is informational only and does not block the PR.

[billyvg]

Visual QA

Screenshots from Scraps stories (fixture data, 1440×900, light theme). "Before" is the #127576 head.

Story coverage: GlobalDrawer renders drawer content where it is mounted, which in Scraps is the page root, outside the story's fixture organization and query client. So a thread opened from a story requested /organizations/sentry-sdks/investigations/commented-invoice-timeouts/ from production (404) and showed an error. Its reply box would also have posted to production. I mounted a GlobalDrawer inside InvestigationFixtureApi, filtered fixture comments by blockId, and gave the query block a thread. That's in a local commit that isn't pushed yet; with it there were zero production calls.

before	after

this branch's stories as-is	with the fixture drawer

deep-linked comment	reply from the drawer

Checked in the browser:

• The thread lists comments oldest first.
• ?comments=open&commentsBlock=…&comment=… highlights the linked comment.
• A reply lands in the thread and at the top of Activity, and the count goes to 8.
• Clicking outside closes the drawer and clears the URL.

Nit: the highlight is hard to see. The secondary background measured rgb(248, 248, 249) on white, so a deep link may not visibly land anywhere.

Story note: threads open from the URL, so on the multi-story Detail page every mounted investigation page opens its own drawer. The new comments story keeps a single page for that reason.