feat(cmdk): Create dynamic command palette action registration

[rbro112]

Creates dynamic actions registration following the approach outlined by https://linear.app/getsentry/issue/DE-719/cmdk-add-api-for-registering-dynamic-actions

Adds the first usage of this dynamic acton with a docs search.

[rbro112]

• ref(cmdk): Update DSN actions to use new dynamic actions #111496
• feat(cmdk): Create dynamic command palette action registration #111495 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[sentry]

Bug: Actions generated from doc search results with identical titles will have the same key, causing one to silently overwrite the other in the command palette.
_{Severity: MEDIUM}

Suggested Fix

Update the key generation logic to ensure uniqueness. Include more information in the key, such as the documentation section or a unique identifier from the search result hit object, to prevent collisions. For example: const actionKey = ${id}:${action.type}:${hit.section}:${slugify(action.display.label)}`;.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: static/app/components/commandPalette/useDocsSearchActions.tsx#L63-L71

Potential issue: The key for command palette actions is generated by slugifying the
action's label. In `useDocsSearchActions.tsx`, actions are created from documentation
search results. If two search results from different sections (e.g., 'docs' and
'develop') have the same title, they will produce identical keys after slugification.
The reducer in `context.tsx` handles key collisions by overwriting the existing action
with the new one. This causes one of the search results to be silently dropped from the
command palette, making it inaccessible to the user without any warning.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

General approach: replace the ad‑hoc regex-based HTML stripper with a more robust, well-tested sanitization strategy that cannot reintroduce <script or other tags via multi-character replacement quirks. Since this is a React/TypeScript frontend, a small, focused HTML sanitizer library is appropriate and avoids implementing brittle custom logic.

Best concrete fix here: import a lightweight sanitizer such as dompurify and use it to produce safe, plain text from the Algolia result fields. Specifically:

• Add an import for DOMPurify at the top of useDocsSearchActions.tsx.
• Rewrite stripHtml so that it:
  1. Sanitizes the input HTML with DOMPurify.
  2. Extracts text content without any tags. For a robust solution that doesn’t depend on browser DOM APIs (which can be problematic in SSR), DOMPurify provides DOMPurify.sanitize(html, {ALLOWED_TAGS: [], ALLOWED_ATTR: []}) to remove all tags, leaving only text.
• Ensure highlightMarks continues to operate on the original Algolia-marked HTML string, but when it produces non-highlighted text fragments, it uses our new stripHtml implementation, which is now robust.

Concretely:

• In static/app/components/commandPalette/useDocsSearchActions.tsx, modify stripHtml to call DOMPurify.sanitize(html, {ALLOWED_TAGS: [], ALLOWED_ATTR: []}) instead of using html.replace(/<[^>]*>/g, '').
• Add an import at the top: import DOMPurify from 'dompurify';

This keeps all existing behavior (returning plain text for labels and non-highlighted fragments) but uses a correct, repeatable, and library-backed sanitization that won’t suffer from incomplete multi-character replacement issues.

[getsantry]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you remove the label Waiting for: Community, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀