69 lines
4.8 KiB
Markdown
69 lines
4.8 KiB
Markdown
---
|
|
description: Pick or fix a Sentry issue end-to-end, then PR and watch CI
|
|
argument-hint: "[issue-id-or-url]"
|
|
---
|
|
Run Sentry issue repair workflow for this project only.
|
|
|
|
Input: `$ARGUMENTS`
|
|
|
|
Goal:
|
|
1. Use provided Sentry issue id or URL. If none provided, choose the highest-impact unresolved issue using frequency, affected users, recency, and production impact.
|
|
2. Create/switch to git branch named exactly after the Sentry short issue id.
|
|
3. Investigate root cause, implement fix, and add/update tests.
|
|
4. Open PR and watch CI until green.
|
|
|
|
Rules:
|
|
- Protect local work. Start with `git status --short`. If uncommitted changes exist, stop and ask before branching.
|
|
- Never expose secrets. Do not print tokens, `.env`, Sentry auth, DB URLs, or PII.
|
|
- Use the Sentry CLI (`sentry`) first. Prefer stored OAuth login over env build tokens; if `SENTRY_AUTH_TOKEN` is invalid or too narrow, run CLI commands as `env -u SENTRY_AUTH_TOKEN sentry ...` unless `SENTRY_FORCE_ENV_TOKEN=1` is intentionally set.
|
|
- Never print raw Sentry JSON that may contain PII. Redact emails, user IDs when summarizing. Keep secrets out of output.
|
|
- For Laravel ecosystem changes, use `application-info` and `search-docs` before code changes.
|
|
- Activate/read relevant project skills when touched: Pest tests, Inertia React, Wayfinder, Tailwind, Fortify, Pennant.
|
|
- Every code change needs programmatic verification. Add or update a focused Pest/test when feasible. Run minimum affected tests. Run `vendor/bin/pint --dirty --format agent` after PHP edits.
|
|
- Prefer small surgical fix. No dependency changes without approval.
|
|
|
|
Workflow:
|
|
1. Identify issue:
|
|
- Confirm auth and org/project access with `sentry auth status`, `sentry org list --json`, and `sentry project list <org> --json` when needed.
|
|
- If `$ARGUMENTS` is a Sentry URL, extract `/issues/<numeric-id>/` or the visible short issue id, then fetch it with `sentry issue view <issue> --json --fields id,shortId,title,culprit,permalink,level,status,substatus,count,userCount,firstSeen,lastSeen,project,metadata,priority,platform,isUnhandled`.
|
|
- If `$ARGUMENTS` is a bare issue id or short id, fetch it with `sentry issue view <issue> --json --fields id,shortId,title,culprit,permalink,level,status,substatus,count,userCount,firstSeen,lastSeen,project,metadata,priority,platform,isUnhandled`.
|
|
- If no args, list unresolved production issues with both frequency and user sorting, then compare top results:
|
|
- `sentry issue list <org>/<project> --query 'is:unresolved environment:production' --sort freq --limit 25 --json --fields id,shortId,title,culprit,count,userCount,lastSeen,permalink,priority,metadata,project`
|
|
- `sentry issue list <org>/<project> --query 'is:unresolved environment:production' --sort user --limit 25 --json --fields id,shortId,title,culprit,count,userCount,lastSeen,permalink,priority,metadata,project`
|
|
- Pick best impact score: high event count, high user count, recent lastSeen, production environment, clear actionable stack.
|
|
- Record chosen short issue id and Sentry URL in notes.
|
|
2. Branch:
|
|
- Derive branch name from Sentry short issue id only, e.g. `WHISPER-MONEY-123`.
|
|
- Run `git switch -c <issue-id>`; if branch exists, `git switch <issue-id>`.
|
|
3. Investigate:
|
|
- Fetch latest issue details and spans with `sentry issue view <issue> --spans all --json`.
|
|
- Fetch recent events with `sentry issue events <issue> --limit 10 --full --json`.
|
|
- Extract stack trace, breadcrumbs, environment, release, tags, URLs/routes, affected users count, trace/span data, and suspect queries. Redact PII in notes.
|
|
- For event details if needed, use `sentry event view <event-id> --json` or `sentry api <endpoint> --json`.
|
|
- Reproduce locally using tests or focused command. Inspect app logs/browser logs if relevant.
|
|
- If root cause not obvious after issue/event data, run Seer with `sentry issue explain <issue> --json` and/or `sentry issue plan <issue> --json`.
|
|
4. Fix:
|
|
- Read nearby code and conventions first.
|
|
- Implement minimal fix.
|
|
- Add regression test covering Sentry failure path.
|
|
5. Verify:
|
|
- Run targeted test command, e.g. `php artisan test --compact --filter=<test-or-class>`.
|
|
- Run lint/format commands required by touched files.
|
|
- If failures occur, fix and rerun until pass.
|
|
6. PR:
|
|
- Commit changes with concise conventional commit.
|
|
- Push branch.
|
|
- Create PR with `gh pr create`, including Sentry issue link, root cause, fix summary, and verification commands.
|
|
- Get PR number from `gh pr view --json number --jq .number` if needed.
|
|
- Watch CI every 10 seconds with `gh pr checks <number> --watch --fail-fast --interval 10`.
|
|
- If CI fails, inspect logs, fix, commit/push, and watch again until green.
|
|
|
|
Output when done:
|
|
- Issue id + Sentry URL
|
|
- Branch name
|
|
- Root cause
|
|
- Fix summary
|
|
- Tests/commands run
|
|
- PR URL
|
|
- CI status
|