|
| 1 | +# Sentry Logged Errors Fix Skill |
| 2 | + |
| 3 | +This skill provides a systematic workflow for retrieving errors from Sentry, analyzing root causes, fixing code issues, and creating pull requests. |
| 4 | + |
| 5 | +## Prerequisites |
| 6 | + |
| 7 | +- **SENTRY_API_TOKEN**: Add to `.env` file (get from Sentry → Settings → API → Auth Tokens) |
| 8 | +- **SENTRY_ORG**: Your Sentry organization slug |
| 9 | +- **SENTRY_PROJECT**: Your Sentry project slug |
| 10 | +- **Dependencies**: Load `error-handling.md` skill before using this skill |
| 11 | + |
| 12 | +## Workflow |
| 13 | + |
| 14 | +### 1. Configure Environment |
| 15 | + |
| 16 | +Add to your `.env` file: |
| 17 | +```bash |
| 18 | +SENTRY_API_TOKEN=your_token_here |
| 19 | +SENTRY_ORG=your_org_slug |
| 20 | +SENTRY_PROJECT=your_project_slug |
| 21 | +``` |
| 22 | + |
| 23 | +### 2. Retrieve Recent Errors from Sentry |
| 24 | + |
| 25 | +Use Sentry API to fetch errors from the last 24 hours, sorted by frequency: |
| 26 | + |
| 27 | +``` |
| 28 | +GET https://sentry.io/api/0/projects/{SENTRY_ORG}/{SENTRY_PROJECT}/issues/ |
| 29 | + ?statsPeriod=24h |
| 30 | + &sort=freq |
| 31 | + &limit=50 |
| 32 | +``` |
| 33 | + |
| 34 | +Headers: |
| 35 | +``` |
| 36 | +Authorization: Bearer {SENTRY_API_TOKEN} |
| 37 | +``` |
| 38 | + |
| 39 | +**Key fields to extract:** |
| 40 | +- `id` - Issue ID |
| 41 | +- `title` - Error title/message |
| 42 | +- `culprit` - Function/method where error occurred |
| 43 | +- `metadata.value` - Error details |
| 44 | +- `count` - Frequency (for prioritization) |
| 45 | +- `level` - Severity (error, warning, etc.) |
| 46 | +- `lastSeen` - Most recent occurrence |
| 47 | + |
| 48 | +### 3. Get Error Details and Stack Trace |
| 49 | + |
| 50 | +For each error to fix, retrieve detailed information: |
| 51 | + |
| 52 | +``` |
| 53 | +GET https://sentry.io/api/0/issues/{ISSUE_ID}/events/latest/ |
| 54 | +``` |
| 55 | + |
| 56 | +**Extract:** |
| 57 | +- Full stack trace with file paths and line numbers |
| 58 | +- Error context (variables, state) |
| 59 | +- Breadcrumbs (user actions leading to error) |
| 60 | +- Tags (environment, release, user info) |
| 61 | + |
| 62 | +### 4. Analyze Root Cause |
| 63 | + |
| 64 | +For each error: |
| 65 | + |
| 66 | +1. **Locate the problematic code** using stack trace file paths and line numbers |
| 67 | +2. **Examine error context** to understand the failure scenario |
| 68 | +3. **Check related code** for similar patterns that might have the same issue |
| 69 | +4. **Identify the root cause**: |
| 70 | + - Missing null/undefined checks |
| 71 | + - Unhandled promise rejections |
| 72 | + - Missing error handling in async operations |
| 73 | + - Type mismatches |
| 74 | + - Race conditions |
| 75 | + - Missing retry logic for network calls |
| 76 | + |
| 77 | +### 5. Fix Code Following Error Handling Guidelines |
| 78 | + |
| 79 | +Apply fixes based on the `error-handling.md` skill: |
| 80 | + |
| 81 | +#### Check Severity Level |
| 82 | +- **ERROR level**: Unexpected system failures, critical issues |
| 83 | +- **WARN level**: User-related errors (401, 403, 4xx status codes) |
| 84 | +- **DEBUG level**: Expected errors, informational only |
| 85 | + |
| 86 | +#### Implement Fix with Proper Logging |
| 87 | +```typescript |
| 88 | +try { |
| 89 | + // operation |
| 90 | +} catch (error) { |
| 91 | + // Choose appropriate level based on error type |
| 92 | + if (isUserError(error)) { |
| 93 | + logger.warn('User operation failed', error); |
| 94 | + } else { |
| 95 | + logger.error('System operation failed', error); |
| 96 | + } |
| 97 | + |
| 98 | + // Ensure dual logging to Sentry AND Amplitude |
| 99 | + sentryClient.captureException(error); |
| 100 | + amplitudeClient.logEvent('error_occurred', { error: error.message }); |
| 101 | +} |
| 102 | +``` |
| 103 | + |
| 104 | +#### Handle Retry Loops Correctly |
| 105 | +```typescript |
| 106 | +let lastError; |
| 107 | +for (let attempt = 0; attempt < maxRetries; attempt++) { |
| 108 | + try { |
| 109 | + return await operation(); |
| 110 | + } catch (error) { |
| 111 | + lastError = error; |
| 112 | + // Only log on final failure |
| 113 | + if (attempt === maxRetries - 1) { |
| 114 | + logger.error('Operation failed after retries', error); |
| 115 | + sentryClient.captureException(error); |
| 116 | + amplitudeClient.logEvent('retry_exhausted', { attempts: maxRetries }); |
| 117 | + } |
| 118 | + } |
| 119 | +} |
| 120 | +``` |
| 121 | + |
| 122 | +#### Avoid Duplicate Logging |
| 123 | +- Log each error only once at the appropriate level |
| 124 | +- If re-throwing, don't log again at higher levels |
| 125 | +- Check if error has already been logged |
| 126 | + |
| 127 | +### 6. Create Branch and Commit Fix |
| 128 | + |
| 129 | +Use GitHub MCP tools: |
| 130 | + |
| 131 | +```typescript |
| 132 | +// 1. Create a branch |
| 133 | +create_branch({ |
| 134 | + owner: "repo-owner", |
| 135 | + repo: "repo-name", |
| 136 | + branch: "fix/sentry-{ISSUE_ID}-{short-description}", |
| 137 | + from_branch: "main" |
| 138 | +}) |
| 139 | + |
| 140 | +// 2. Commit the fix |
| 141 | +push_files({ |
| 142 | + owner: "repo-owner", |
| 143 | + repo: "repo-name", |
| 144 | + branch: "fix/sentry-{ISSUE_ID}-{short-description}", |
| 145 | + files: [ |
| 146 | + { |
| 147 | + path: "path/to/fixed/file.ts", |
| 148 | + content: "fixed-file-content" |
| 149 | + } |
| 150 | + ], |
| 151 | + message: "fix: resolve {error-title} (Sentry #{ISSUE_ID})\n\nFixes error occurring {count} times in last 24h.\n\nRoot cause: {description}\nSolution: {solution-description}" |
| 152 | +}) |
| 153 | +``` |
| 154 | + |
| 155 | +### 7. Validate Fix |
| 156 | + |
| 157 | +Before creating PR: |
| 158 | + |
| 159 | +1. **Run relevant tests**: |
| 160 | + ```bash |
| 161 | + npm test -- path/to/fixed/file.test.ts |
| 162 | + ``` |
| 163 | + |
| 164 | +2. **Run linting**: |
| 165 | + ```bash |
| 166 | + npm run lint:fix |
| 167 | + ``` |
| 168 | + |
| 169 | +3. **Verify the fix addresses the root cause**, not just symptoms |
| 170 | + |
| 171 | +### 8. Create Pull Request |
| 172 | + |
| 173 | +```typescript |
| 174 | +create_pull_request({ |
| 175 | + owner: "repo-owner", |
| 176 | + repo: "repo-name", |
| 177 | + title: "fix: resolve {error-title} (Sentry #{ISSUE_ID})", |
| 178 | + body: `## Problem |
| 179 | +Error occurring ${count} times in last 24 hours. |
| 180 | +
|
| 181 | +**Sentry Issue**: https://sentry.io/organizations/{org}/issues/{ISSUE_ID}/ |
| 182 | +
|
| 183 | +**Error**: ${error_message} |
| 184 | +
|
| 185 | +**Root Cause**: ${root_cause_description} |
| 186 | +
|
| 187 | +## Solution |
| 188 | +${solution_description} |
| 189 | +
|
| 190 | +## Testing |
| 191 | +- [ ] Unit tests pass |
| 192 | +- [ ] Linting passes |
| 193 | +- [ ] Manual testing completed |
| 194 | +- [ ] Follows error-handling.md guidelines |
| 195 | +
|
| 196 | +## Checklist |
| 197 | +- [ ] Appropriate severity level (ERROR/WARN/DEBUG) |
| 198 | +- [ ] Dual logging to Sentry and Amplitude |
| 199 | +- [ ] No duplicate logging |
| 200 | +- [ ] Retry logic handles errors correctly (if applicable) |
| 201 | +`, |
| 202 | + head: "fix/sentry-{ISSUE_ID}-{short-description}", |
| 203 | + base: "main", |
| 204 | + draft: false |
| 205 | +}) |
| 206 | +``` |
| 207 | + |
| 208 | +## Prioritization Strategy |
| 209 | + |
| 210 | +Process errors in this order: |
| 211 | +1. **Highest frequency first** (most impactful) |
| 212 | +2. Within same frequency, prioritize by severity |
| 213 | +3. Group similar errors and fix together when possible |
| 214 | + |
| 215 | +## Batch Processing Tips |
| 216 | + |
| 217 | +For efficiency when fixing multiple errors: |
| 218 | + |
| 219 | +1. **Group by root cause** - Multiple errors might stem from same issue |
| 220 | +2. **Fix similar patterns** - If one file has an issue, check others with same pattern |
| 221 | +3. **Create one PR per logical fix** - Don't combine unrelated fixes |
| 222 | +4. **Limit to 5-10 errors per session** - Avoid overwhelming reviewers |
| 223 | + |
| 224 | +## Error Fix Checklist |
| 225 | + |
| 226 | +Before submitting each PR: |
| 227 | +- [ ] Root cause identified and addressed |
| 228 | +- [ ] Fix follows `error-handling.md` guidelines |
| 229 | +- [ ] Appropriate severity level used |
| 230 | +- [ ] Dual logging (Sentry + Amplitude) implemented |
| 231 | +- [ ] No duplicate logging |
| 232 | +- [ ] Retry logic correct (if applicable) |
| 233 | +- [ ] Tests pass |
| 234 | +- [ ] Linting passes |
| 235 | +- [ ] PR description links to Sentry issue |
| 236 | +- [ ] PR includes before/after context |
| 237 | + |
| 238 | +## Common Error Patterns and Fixes |
| 239 | + |
| 240 | +### Pattern 1: Unhandled Promise Rejections |
| 241 | +```typescript |
| 242 | +// Before (error prone) |
| 243 | +async function fetchData() { |
| 244 | + const data = await apiCall(); // Can throw |
| 245 | + return data; |
| 246 | +} |
| 247 | + |
| 248 | +// After (proper error handling) |
| 249 | +async function fetchData() { |
| 250 | + try { |
| 251 | + const data = await apiCall(); |
| 252 | + return data; |
| 253 | + } catch (error) { |
| 254 | + logger.error('Failed to fetch data', error); |
| 255 | + throw error; // Re-throw if caller should handle |
| 256 | + } |
| 257 | +} |
| 258 | +``` |
| 259 | + |
| 260 | +### Pattern 2: Missing Null Checks |
| 261 | +```typescript |
| 262 | +// Before |
| 263 | +const userName = user.profile.name; // user or profile might be null |
| 264 | + |
| 265 | +// After |
| 266 | +const userName = user?.profile?.name ?? 'Unknown'; |
| 267 | +``` |
| 268 | + |
| 269 | +### Pattern 3: Network Errors Without Retry |
| 270 | +```typescript |
| 271 | +// Before |
| 272 | +const response = await fetch(url); |
| 273 | + |
| 274 | +// After (with retry) |
| 275 | +let lastError; |
| 276 | +for (let attempt = 0; attempt < 3; attempt++) { |
| 277 | + try { |
| 278 | + const response = await fetch(url); |
| 279 | + return response; |
| 280 | + } catch (error) { |
| 281 | + lastError = error; |
| 282 | + if (attempt === 2) { |
| 283 | + logger.error('Fetch failed after retries', error); |
| 284 | + } |
| 285 | + await sleep(1000 * (attempt + 1)); // Exponential backoff |
| 286 | + } |
| 287 | +} |
| 288 | +throw lastError; |
| 289 | +``` |
| 290 | + |
| 291 | +## Notes |
| 292 | + |
| 293 | +- Always load the `error-handling.md` skill before starting fixes |
| 294 | +- Update `.env.example` if adding new Sentry configuration variables |
| 295 | +- Link Sentry issues in commit messages and PR descriptions |
| 296 | +- Consider resolving the Sentry issue after PR is merged |
0 commit comments