Repository navigation
fix(mcp): Start a new Seer run when the last one failed - #2198
Merged
Merged
Conversation
analyze_issue_with_seer returned any existing finished run as is, so a run that stopped because the org was out of credits could never be retried after a top-up. Like the CLI, start a new run whenever the last one ended in error, and keep polling until Sentry returns the new run so the old failure isn't reported as the result. Fixes CW-3094 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
The added "then run the analysis again" read as if the billing admin should rerun the analysis. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Retrying a failed run is an implementation detail the agent doesn't need in the tool description. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A run that ran out of credits partway through can already hold a root cause. If the restart is refused with a 402, show that partial analysis instead of only "Analysis Not Started". Drop the stale-run guard while polling. Sentry creates the run before the POST returns and the GET returns the most recently triggered run, so the old failed run never comes back. When the IDs do differ, another caller started a run after ours, and the guard made us wait out the full timeout. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
srest2021
approved these changes
Nov 12, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…-mcp-restart-failed-seer-run # Conflicts: # packages/mcp-core/src/tools/catalog/analyze-issue-with-seer.test.ts
vaind
enabled auto-merge (squash)
November 13, 2026 09:31
BYK
pushed a commit
that referenced
this pull request
Nov 13, 2026
Sentry refuses to start a new Autofix run with a 409 when the org has no GitHub/GitLab integration or the issue's project has no linked repositories. The body carries a `code` (`scm_integration_required` or `repos_not_linked`) and a `detail` (sentry `src/sentry/seer/endpoints/group_ai_autofix.py`: `_check_autofix_setup` at :204-220, the 409 at :510-520). Orgs on the legacy `seer-added` plan skip the check. This was reported through Sentry MCP user feedback: Seer analysis returned HTTP 409 requiring connected repositories, and the tool prerequisites don't mention repository connection. ### MCP: `analyze_issue_with_seer` The tool handled the 402 out-of-credits case but rethrew this 409. The error handler then turned it into a generic **Input Error** that tells the agent to fix its input and try again (`internal/error-handling.ts:292-303`). The tool description didn't mention the prerequisite either. Now the tool returns `## Analysis Not Started` with Sentry's `detail` and says that retrying won't help until the setup is done, the same way it handles the 402. The tool hints now say that a new analysis needs an SCM integration and repositories linked to the project. Any other 409 still throws. The tool's POST sends only `user_context`, with no `run_id` or `step`, so it's always a kickoff, and the setup gate is the only 409 a kickoff can hit (`group_ai_autofix.py`:369-407 and :505-520). ### CLI: `issue explain` / `issue plan` Before, the CLI passed the 409 through as a plain `ApiError`, which exits with 30 and shows only Sentry's detail. Now `createSeerError` maps both codes to new `SeerError` reasons, `scm_integration_required` and `repos_not_linked`. These say what's missing and link the page that fixes it: the source code integrations directory, or the org's Seer settings, where Sentry keeps the project-to-repo links it checks (`SeerProjectRepository`). Both reasons exit with a new code, **44 `SEER_SETUP_REQUIRED`**. I added it to `exit-codes.md` and `packages/cli/AGENTS.md`. No trial hint, since a trial doesn't fix setup. Other 409s, such as `run_in_flight` from `issue plan` continuing a run, stay `ApiError`s. **Reporting change to review:** on SaaS, `SeerError` is deliberately still captured, because it feeds the Seer upsell dashboard (`error-reporting.ts:186-191`). These 409s were silenced before, as `api_user_error`. After this PR, CLI setup 409s on SaaS show up as `SeerError` events tagged with their reason. That fits the existing "SeerError is a product signal" rule, but it's a volume change. If you'd rather keep them silenced, add them to the silence list. ### Tests - **MCP:** I added `explains why the run did not start when Sentry answers 409` (both codes) and `still throws a 409 that is not a setup code`. The new 409 cases fail without the fix. The full `mcp-core` vitest run passes, and so does `tsc --noEmit`. - **CLI:** I added `createSeerError` cases (both codes, plus `run_in_flight` staying null), `SeerError` format and exit-code cases, and an `issue explain` func test for a `repos_not_linked` 409. The new createSeerError and explain cases fail without the fix. `tsc --noEmit` passes. - In my sandbox, the full CLI unit run has failures in unrelated files. The same failures happen without this change (for example, hints render `npx -y sentry` because of how the sandbox launches the CLI, plus EACCES and DNS tests). I compared `test/commands/issue/utils.test.ts` with and without the change, and the failures were identical. CI is authoritative here. - **Both:** oxlint and oxfmt pass on the changed files. - **Not done:** I didn't run the root `pnpm run lint`/`test`, and I didn't QA either path against a live org that has no repos linked. **Heads-up:** #2198 changes the same MCP handler (it restarts failed runs). The two changes don't overlap, but whichever lands second needs a rebase. <!-- junior-request-attribution:start --> via **Sentry**, @BYK. <!-- junior-request-attribution:end --> <!-- junior-session-footer:start --> <!-- junior-conversation-id:slack%3AC0CG2CP9ELW%3A1794503685.788599 --> -- [View Session](https://junior-prod.sentry.dev/conversations/slack%3AC0CG2CP9ELW%3A1794503685.788599) [[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC0CG2CP9ELW%3A1794503685.788599/?project=4510944073809921) <!-- junior-session-footer:end --> --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes CW-3094
analyze_issue_with_seerreturns an issue's existing run as soon as it has finished, and that includes failed runs. A run that stopped because the org ran out of Seer credits keeps coming back as the result, so it can't be retried after someone tops up. Follow-up to #2031, from this review thread.The tool now starts a new run whenever the last one ended in
error, whatever the reason, matching the CLI (#2150). Completed and waiting-for-input runs are still returned as they are. If the org is still out of credits, the new start gets a 402, which the tool already explains as "Analysis Not Started". It now also shows whatever the failed run found before it stopped, such as a root cause.Tested manually against sentry.io with the local stdio server. On an issue whose last run had failed, the tool started a new run and returned its root cause, and the issue's latest run is now the completed one. The 402 path is covered only by unit tests, since it needs an org that's out of credits.
🤖 Generated with Claude Code