fix: guard against null status in seer API, plan command, and monitor schedule formatting - #1104
Conversation
When the Seer API returns an autofix state with a null or missing status field, normalizeAgentStatus() would call status.toUpperCase() on the default branch, throwing a TypeError. This can happen when an autofix run is freshly created and has not yet received a status update. Default to 'PROCESSING' when status is falsy, matching the initial state of a new autofix run. Co-authored-by: Miguel Betegón <miguelbetegongarcia@gmail.com>
When ensureRootCauseAnalysis returns with WAITING_FOR_USER_RESPONSE status (meaning the user needs to select a root cause in the Sentry web UI), the plan command would proceed to call triggerSolutionPlanning anyway. This causes confusing failures or empty results. Now checks the state status after root cause analysis completes and throws a clear CliError directing the user to the Sentry UI. Also handles WAITING_FOR_USER_RESPONSE during solution polling to avoid the misleading 'could not identify a code fix' message. Relates to GitHub issue #958. Co-authored-by: Miguel Betegón <miguelbetegongarcia@gmail.com>
When a monitor's interval schedule array has fewer than 2 elements (e.g. an empty array or single-element array from a misconfigured monitor), the formatter would produce 'every undefined undefined' in the SCHEDULE column. Added a length check before accessing schedule[0] and schedule[1], falling back to stringifying the first element for short arrays. Co-authored-by: Miguel Betegón <miguelbetegongarcia@gmail.com>
|
Codecov Results 📊❌ Patch coverage is 12.50%. Project has 5021 uncovered lines. Files with missing lines (3)
Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
- Coverage 81.19% 81.17% -0.02%
==========================================
Files 383 383 —
Lines 26651 26659 +8
Branches 17354 17364 +10
==========================================
+ Hits 21638 21638 —
- Misses 5013 5021 +8
- Partials 1798 1802 +4Generated by Codecov Action |
|
Jared, can you take over this PR, resolve merge conflicts and address my comment? |
|
Jared, resolve the messages by byk and the merge issues |
Bring the branch up to date with the monorepo restructure (src/ -> packages/cli/src/). The three fixes reapply cleanly onto the new layout.
When root cause analysis pauses on WAITING_FOR_USER_RESPONSE, interactive sessions now present the candidate root causes and let the user pick one in the terminal so planning can continue, instead of always erroring out. JSON output and non-TTY runs keep the clear Sentry-UI hint. Addresses BYK's review feedback on #1104.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
done on both fronts. merge issues — the branch had drifted behind byk's review — his ask was "instead of throwing, can we not get the user input here in the terminal?" on the |
|
not enabling auto-merge here — the diff is 188 lines changed across 4 files (over the 150-line auto-merge threshold, mostly the new plan.func.test.ts), and it's tagged |
There was a problem hiding this comment.
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.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 9be98b1. Configure here.
|
Jared, fix all Seer and Cursor findings, get the patch coverage above 80% and then you can merge if there are no more comments after that round. |
The interactive prompt captured the user's selection but never submitted it, then advanced a run still in WAITING_FOR_USER_RESPONSE — flagged by Seer and Cursor review. Sentry has no CLI-facing endpoint to submit a specific cause_id (root-cause selection among candidates happens in the web UI), so make this a confirm-to-continue: show the identified root cause, ask whether to plan, and only then advance via triggerSolutionPlanning (the same step the Sentry UI uses). Declining or a non-TTY/JSON run keeps the clear Sentry-UI error. Add coverage: interactive confirm/decline/cancel, post-planning terminal states, existing-solution short-circuit, normalizeAgentStatus null guard, and formatSchedule edge cases.
|
the bugbot finding (root cause selection never submitted) is fixed in 4a9c354 — same fix as the inline threads, which are now resolved. the captured selection was being discarded; since Sentry has no CLI-facing endpoint to submit a specific cause_id, this is now a confirm-to-continue that advances the run via triggerSolutionPlanning (the same step the web UI uses), with the open-in-Sentry error retained for non-interactive/JSON runs. covered by new confirm/decline/cancel tests. |
|
on it. status:
i won't merge while required checks are still running — they're pending right now. once they're green and assuming no new review comments land, i'll squash-merge per your go-ahead. |
|
Jared - fix lint/typecheck too (see CI failure) and we should be good |
CI's biome formatter requires the multi-line signature after the export.
|
fixed in cdeb04c — the CI failure was a biome formatter rule (it wanted the |

Summary
Three independent bug fixes for crashes and logic errors found via codebase analysis and issue triage.
Fix 1:
normalizeAgentStatusTypeError on null/undefined statusRoot cause:
normalizeAgentStatus()insrc/lib/api/seer.tscallsstatus.toUpperCase()in its default branch, which throwsTypeErrorwhen the Seer API returns an autofix state with a null or missingstatusfield (e.g. a freshly created run).Reproduction: Call
sentry issue explainorsentry issue planagainst an issue where the autofix API response hasautofix.statusas null or undefined.Fix: Added a null/undefined guard that defaults to
"PROCESSING"— matching the initial state of a new autofix run.Fix 2:
plancommand proceeds to solution planning when root cause needs user input (GitHub #958)Root cause: When
ensureRootCauseAnalysisreturns withWAITING_FOR_USER_RESPONSEstatus (user needs to select a root cause in the Sentry web UI), the plan command proceeds to calltriggerSolutionPlanninganyway, causing confusing failures or empty results.Reproduction: Run
sentry issue plan <issue>on an issue where root cause analysis is waiting for user input to select a root cause.Fix: Added a status check after
ensureRootCauseAnalysisthat throws a clearCliErrordirecting the user to the Sentry UI. Also added aWAITING_FOR_USER_RESPONSEcheck after solution polling to avoid the misleading "could not identify a code fix" message.Fix 3:
formatScheduleunguarded array access in monitor listRoot cause:
formatSchedule()insrc/commands/monitor/list.tsaccessesconfig.schedule[0]andconfig.schedule[1]without checking array length, producing"every undefined undefined"for empty or single-element schedule arrays.Reproduction:
sentry monitor listagainst an org with a monitor whose interval schedule array has fewer than 2 elements.Fix: Added a
schedule.length < 2guard that falls back to stringifying the first element for malformed arrays.