Diagnosing Stacktrace Symbolication

1---
2name: diagnosing-stacktrace-symbolication
3description: >
4  Help users debug PostHog Error Tracking stack-trace symbolication for any supported platform — JavaScript/TypeScript
5  web, React Native (Hermes), Android (Proguard / R8), or iOS / macOS (dSYM). The PostHog symbol-set lookup flow is
6  universal across platforms; build-tool and artifact details live in per-platform references (JavaScript is fleshed
7  out, others come as we encounter them). Use when stack frames stay minified or obfuscated after symbols are
8  uploaded, PostHog symbol sets show last_used but frames are not readable, chunk IDs or dSYM UUIDs do not match,
9  "Token not found" appears, uploaded source maps / dSYMs / Proguard mappings look empty, or bundler /
10  symbol-upload configuration needs troubleshooting.
11---
12 
13# Diagnosing stack-trace symbolication
14 
15Symbolication is the cross-platform name for what JavaScript source-map lookup, Hermes function-offset resolution,
16Proguard / R8 demangling, and dSYM address-to-line lookup all do — turn a minified or obfuscated frame back into a
17readable file, function, and line.
18 
19Work through the user's build and PostHog symbol sets as one pipeline: build config -> generated symbol artifacts
20(JavaScript source maps, Hermes maps, Proguard mappings, or dSYM bundles) -> uploaded symbol set in PostHog ->
21captured error frame. Most failures become obvious once those four pieces are checked in order.
22 
23## Platforms
24 
25| Platform                    | Symbol-data type | Reference                                   |
26| --------------------------- | ---------------- | ------------------------------------------- |
27| JavaScript / TypeScript web | source-and-map   | [javascript.md](./references/javascript.md) |
28| React Native (Hermes)       | hermes           | _coming soon_                               |
29| Android (Proguard / R8)     | proguard         | _coming soon_                               |
30| iOS / macOS (dSYM)          | apple-dsym       | _coming soon_                               |
31 
32Step 3 of the workflow (symbol-set lookup in PostHog) is identical across platforms — `posthog-cli symbol-sets
33extract` handles all four container types. Steps 1, 2, and the platform-specific failure modes live in the
34per-platform reference.
35 
36## Workflow
37 
38### Step 1 - Find how symbol data is produced and uploaded
39 
40Look at the app repo's build scripts and PostHog upload config. Confirm which PostHog package handles the upload
41(`@posthog/rollup-plugin`, `@posthog/webpack-plugin`, `@posthog/nextjs-config`, `@posthog/nuxt`, or direct
42`posthog-cli`) and which directory or asset it processes. See the platform reference for build-tool-specific
43config inspection.
44 
45For debugging, prefer a build where symbol artifacts remain on disk after upload so you can compare local
46artifacts against what PostHog received. JavaScript example with the Vite plugin (the platform reference covers
47the equivalent setting for other build tools):
48 
49```ts
50sourcemaps: {
51  enabled: true,
52  deleteAfterUpload: false,
53}
54```
55 
56### Step 2 - Build and inspect local artifacts
57 
58Run the production build that uploads symbols, then inspect the emitted files locally. The exact files and helper
59invocation differ per platform — see the platform reference for the helper command, expected file shape, and common
60build-time pitfalls (notably empty-mappings false positives that look like upload bugs but are actually bundler
61config issues).
62 
63If local artifacts already look wrong, fix the build before debugging the PostHog upload.
64 
65### Step 3 - Check symbol sets in PostHog
66 
67Look up the symbol set whose `ref` matches the captured frame's `chunk_id` using the dedicated MCP tools — they
68handle auth, project scoping, and pagination automatically:
69 
70- `posthog:error-tracking-symbol-sets-list` with `ref=<chunk_id>` returns the matching row.
71- `posthog:error-tracking-symbol-sets-retrieve` with the ID returns the same shape (and confirms permissions).
72- `posthog:error-tracking-symbol-sets-download-retrieve` returns a one-hour presigned URL pointing at the uploaded
73  symbol-data file. Download it immediately; do not echo the URL back unless the user explicitly asks.
74 
75If MCP access is not available, the same data is in **Project settings > Error tracking > Symbol sets** in the
76PostHog UI.
77 
78Interpret the row:
79 
80- `ref` must match the captured frame `chunk_id`.
81- `last_used` updating means PostHog found and loaded that symbol set. It does not guarantee the frame resolved.
82- `has_uploaded_file: false` means the upload did not complete.
83- A non-null `failure_reason` means PostHog could not parse or load the uploaded symbol data.
84 
85The downloaded file is a PostHog symbol-data container (compressed Rust-encoded payload), not plain JSON. Extract
86it with `posthog-cli`:
87 
88```bash
89posthog-cli symbol-sets extract symbolset.bin -o ./extracted
90# or, without installing globally:
91#   npx @posthog/cli symbol-sets extract symbolset.bin -o ./extracted
92#   bunx @posthog/cli symbol-sets extract symbolset.bin -o ./extracted
93```
94 
95`posthog-cli symbol-sets extract` handles all four symbol-set types (source-and-map, hermes, proguard, dSYM) and
96writes the extracted files into the output directory. Once extracted, summarize using the platform reference's
97helper.
98 
99### Step 4 - Compare local, uploaded, and served files
100 
101Use the failure location to decide what to compare:
102 
103- Local artifact empty and uploaded artifact empty: build tool emitted unusable symbols.
104- Local artifact valid but uploaded artifact empty: upload processing selected or packed the wrong data.
105- Uploaded artifact valid but production stack stays minified or obfuscated: compare deployed binary bytes to the
106  binary that was uploaded with the symbols.
107- `Token not found`: PostHog loaded the symbol data but the captured generated position did not match any token in
108  the uploaded artifact. Usually points to a changed binary after upload, wrong line / column capture (JavaScript)
109  or wrong frame offset (Hermes / dSYM), or a symbol-coverage bug.
110 
111### Step 5 - Fix the most likely layer
112 
113Platform-neutral fixes:
114 
115- Upload symbols after the final build output exists, not before a later step rewrites it.
116- Use the latest PostHog build plugin and `posthog-cli`.
117- Re-upload changed assets intentionally when the same `ref` was previously uploaded with different content.
118- Remove deployment-time transforms (CDN minify, edge rewrites, compression) that change the served binary after
119  upload.
120 
121Platform-specific fixes live in the platform reference.
122 
123## Captured frame checks
124 
125From an affected PostHog error event, collect one minified application frame:
126 
127- `filename`
128- `line` or `lineno`
129- `column` or `colno`
130- `function`
131- `chunk_id` (or platform-equivalent symbol-set ref)
132- any `resolve_failure`, especially `Token not found`
133 
134The frame `filename` should match the deployed binary URL. The `chunk_id` should match the symbol set `ref`. The
135captured generated position should point into the same binary that was uploaded with the symbol data.
136 
137## Failure matrix (cross-platform)
138 
139| Evidence                                         | Likely cause                                                            | Next check                                                                    |
140| ------------------------------------------------ | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
141| No `chunk_id` on frames                          | Chunk ID injection missing or SDK frame parser did not map the filename | Inspect deployed binary and raw frame filenames.                              |
142| Symbol set row missing                           | Upload went to another PostHog project/host or skipped this asset       | Compare plugin `projectId`, `host`, and `ref`.                                |
143| `has_uploaded_file: false`                       | Upload did not finish                                                   | Check build logs; compare `posthog-cli` output to the symbol set row.         |
144| Non-null `failure_reason`                        | PostHog could not parse the uploaded symbol data                        | Download via Step 3 and inspect the extracted contents.                       |
145| Uploaded artifact valid, deployed binary differs | Deployment/CDN/post-build transform changed the binary after upload     | Compare deployed bytes to local build output.                                 |
146| `Token not found`                                | Captured position has no token in the uploaded symbol data              | Verify captured position, deployed binary identity, and symbol-data coverage. |
147 
148Platform-specific failure modes (empty `mappings`, missing `sourcesContent`, Hermes function-offset mismatch,
149Proguard class-name drift, dSYM UUID mismatch) live in the platform reference.
150