pippinmole/ghost

public

Source code of Ghost - On Ghost

chore: add the code-review and cleanup skills used for the unslop pass6b064615 days ago100 lines · 4.8 KB

1	# Sentry Error History
2
3	## What this source contains
4
5	Sentry is the archive of things that went wrong. For defensive, corrective, or error-handling code, it often holds the direct motivation: the specific exceptions, stack traces, and frequencies that pushed someone to add a check, catch, retry, or fallback.
6
7	- Issues. Grouped errors with counts, first/last seen timestamps, affected releases, and comments
8	- Events. Individual error instances within an issue (stack traces, tags, user context)
9	- Releases. Deployment records with associated issues (useful for "which version fixed this?")
10	- Replays. Session recordings of user-facing errors (if enabled)
11	- Profiles. Performance profiling data (less useful for "why", more for "how slow")
12	- Issue comments & assignments. Sometimes contain engineer notes on root cause
13
14	The most valuable thing Sentry provides is temporal correlation: "issue X was created 2024-01-02, peaked at 500 events/day, stopped appearing after release v2.14.0 on 2024-01-15, the release that shipped the defensive check."
15
16	## How to search it
17
18	Use the Sentry MCP.
19
20	1. Orient. If you don't know the project slug and organization:
21
22	```
23	find_organizations
24	find_projects
25	```
26
27	2. Search for issues related to the target.
28
29	```
30	search_issues (natural language, e.g., "errors in PaymentService timeout", "unhandled exceptions in uploadFile")
31	```
32
33	Good query components: exception class names the target handles, the function or class name of the target, error message strings the target checks for, the file path of the target.
34
35	3. Narrow by release and time window.
36
37	```
38	search_issue_events (filter by release, time, environment, trace ID, tags)
39	get_issue_tag_values (for an issue, see distribution across versions, users, environments)
40	```
41
42	For a suspected issue, check:
43	- First seen.
44	- Last seen.
45	- Affected releases.
46	- Frequency trajectory.
47
48	4. Pull the full event for context.
49
50	```
51	get_sentry_resource (pass a Sentry URL or type+ID)
52	```
53
54	Does the stack trace pass through the target code? Do the tags and breadcrumbs match the conditions the target defends against?
55
56	5. Check releases that landed near the target.
57
58	```
59	find_releases (around the commit date of the target)
60	```
61
62	Cross-reference release version with the PR's merge date.
63
64	6. Use Seer sparingly.
65
66	```
67	analyze_issue_with_seer
68	```
69
70	Seer produces AI root-cause analyses. Useful as a hypothesis generator, but treat them as inference, not authoritative. The actual events and stack traces are the primary evidence. Seer's narrative is secondary.
71
72	## What good evidence looks like here
73
74	- An issue whose first seen is shortly before the target's PR and
75	- Stack traces that pass through or land on the target function, showing the exact failure mode being defended against
76	- A comment on the issue from the PR author describing the fix
77	- The target's PR description or commit message referencing a Sentry issue URL or ID
78	- An issue with high event counts that stops after the release containing the target
79
80	## Common pitfalls
81
82	- Grouping drift. Sentry groups errors by fingerprint. Refactors or renames can track the "same" error under a new issue ID. If an issue ends abruptly, the error may have just been regrouped. Check for new issues immediately after.
83	- Release correlation is noisy. A release contains many commits. An issue stopping at v2.14.0 doesn't prove the target fixed it. Another change in the same release might have. Cross-reference with the target's exact commit.
84	- Silent fixes. Sometimes the error stops because upstream changed, not because of the defensive code. The correlation suggests the fix. It doesn't prove authorship.
85	- Resolved != fixed. Issues can be marked "resolved" manually without any code change. Treat
86	- Seer hallucinations. Seer can generate confident-sounding explanations that aren't right. Fall back to the actual events, stack traces, and timestamps when making claims.
87	- Sampling. Some projects sample events aggressively. A low event count may just mean high sampling, not a rare error. If in doubt, note the gap.
88
89	## What to return
90
91	For each relevant issue:
92	- Issue ID and title
93	- Project and organization
94	- First seen / last seen timestamps
95	- Event count (and sampling rate if known)
96	- Affected releases
97	- A representative stack trace snippet showing relevance to the target (verbatim excerpt, not summary)
98	- First/last-seen correlation with the target's ship date
99	- Link to the issue
100	- Any author comments or resolution notes