Sentry plugin

Two-way Sentry integration: Sentry errors flow into Mushi’s queue, and Mushi fixes flow back — merging a fix resolves the linked Sentry issue, resolving in Sentry resolves the linked report. The outbound plugin below also mirrors critical Mushi reports into Sentry.

Route Sentry errors into Mushi (inbound)

No plugin needed — this is built into the hosted API:

1. In Sentry: Settings → Developer Settings → Custom Integrations → Create New Integration → Internal Integration. Set its webhook URL to the Receive URL shown on the Mushi Sentry card (<api>/v1/webhooks/sentry?projectId=<your-project-id>), subscribe to the issue resource, enable Alert Rule Action, and give it Issue & Event: Read & Write.
2. In the Mushi console: Integrations → Sentry — paste the integration’s Client Secret as the Webhook secret, plus your org slug, project slug and auth token. Sentry signs every delivery with that secret (Sentry-Hook-Signature, HMAC-SHA256 of the body); Mushi also requires a fresh Sentry-Hook-Timestamp and drops a Request-ID or body it already accepted.
3. To route alerts too: Alerts → Create Alert Rule (issue alert) → action Send a notification via your internal integration.
4. Fire a test alert. The error lands in Reports with a via Sentry badge, a plain-English diagnosis, and a dispatchable fix.

Issues that already exist never fire again. Pull them in with Import on the Sentry card, the import_sentry_issues MCP tool, or POST /v1/admin/projects/<id>/sentry/import with { "issueIds": ["WEB-12"] } (ids or short ids, at most 10) or { "query": "is:unresolved", "limit": 5 }.

For a whole backlog, add "sinceDays": 30 and "limit": 10, then send the nextCursor from each answer back as "cursor" until it comes back null. Running it again is safe: issues already imported answer linked. If one app reports to two Sentry projects (say a frontend and a backend), list the second in sentry_extra_project_slugs and pick it with "sentryProject".

In the console, all of this is on the Sentry card:

• More Sentry projects (edit the card) takes up to 10 extra project slugs, comma-separated. It saves sentry_extra_project_slugs; clearing the field removes them. Over the API, send a string array to PUT /v1/admin/integrations/platform/sentry ({ "sentry_extra_project_slugs": ["sbc-be"] }; [] or null clears it).
• Import existing Sentry issues has a Sentry project picker (shown when more than one project is configured) and a Seen in choice (any time, or the last 7, 14, 30 or 90 days). A windowed search imports 10 at a time; Load next page repeats the same search from where the last page ended until Sentry has no more.

Behavior:

• Deduped per Sentry issue — repeat alerts land on the same report; re-importing a linked issue returns the existing report.
• Regressions reopen — an alert for an already-fixed report flips it to reopened and bumps the regression counter instead of filing a duplicate.
• Resolves both ways — when a Mushi fix PR merges, Mushi resolves the linked Sentry issue through the Sentry API (resolvedInNextRelease, else resolved) and comments the PR link; the fix commit also carries Fixes <SHORT-ID> for Sentry’s GitHub integration. A failed resolve shows on the fix timeline. action: resolved from Sentry resolves the linked Mushi report.
• Fix context — the files named in an imported issue’s stack are indexed right away, and codebase sweeps index stack-frame files of open Sentry-linked reports first.
• Your Sentry alert rules are the noise filter: only alerts you route at the webhook are ingested. Sentry User Feedback submissions are also ingested on the same endpoint.

Setup (outbound plugin)

1. In Mushi: Marketplace → Sentry → Install.
2. Paste your Sentry auth token and org/project slugs.
3. Configure severity threshold (default: P0/P1 only).

Package

@mushi-mushi/plugin-sentry

Pairs with the SDK’s Sentry handshake — reports already carry sentryContext when @sentry/browser is present.

Events