fix(cli): hash the injected snippet variant in event mode

[ablaszkiewicz]

Merge this before #91823, which makes event mode the default.

Problem

• The event mode content hash ignores which snippet a chunk carries.
• The release snippet is longer than the chunk-id snippet. It shifts the generated columns in the map.
• Two builds of one chunk can therefore share a hash and ship different maps.
• The server keeps the first map. Frames then resolve to wrong source positions.

Changes

• The event mode content hash now covers which snippet the chunk carries.
• The hash still ignores the release id, so a new release does not re-upload every chunk.

How did you test this code?

• cargo test in cli/.
• test_event_mode_content_hash_tracks_the_snippet_variant covers both directions. It fails against the previous hash.
• I measured the hash on a real esbuild bundle from error-tracking-examples/web-raw. The old code returns one hash for both snippet variants. The new code returns two.
• I ran sourcemap process against a local PostHog with both binaries. Both uploaded the second build. That run does not separate them, so it is evidence of no regression rather than evidence of the fix.
• Not run: an upload against PostHog Cloud.

Hash measured on the esbuild bundle

Same pristine index.js and index.js.map, injected twice.

# old code
PROBE releaseless     = 7687592a09eea292e2fb51636992edce9d9101eeb6a004a94b24288f45281b064de4c38b74c538c0058f0d3ca6fb849dd65ced17957453f9cadcf2e2fde7fbfa
PROBE with_release    = 7687592a09eea292e2fb51636992edce9d9101eeb6a004a94b24288f45281b064de4c38b74c538c0058f0d3ca6fb849dd65ced17957453f9cadcf2e2fde7fbfa
PROBE variant_differs = false

# new code
PROBE releaseless      = 849e71e009f6727739a5ba7bd6226bc0dd34bf826f4eff52fe45ce084435cfecc275a77b628c4e46dd001f63fe9535c0703630573da6b42e00aec4736f5bb2c8
PROBE with_release     = 5d69732f9e61fea62b9e02eb9b1354fdd6c7c4b347a1a92ca6e70831d07d69538d7571e531e94b0721e492cbcc0a5e8f93d096496d02d8562d29f20776df054c
PROBE other_release    = 5d69732f9e61fea62b9e02eb9b1354fdd6c7c4b347a1a92ca6e70831d07d69538d7571e531e94b0721e492cbcc0a5e8f93d096496d02d8562d29f20776df054c
PROBE variant_differs  = true
PROBE uuid_stable      = true

uuid_stable is the property the hash has to keep. A second release id leaves the map identical, so the hash must not move.

posthog-cli sourcemap process against a local PostHog

One chunk, uploaded three times. Step 2 repeats step 1 and confirms the server stores and compares the hash.

# old binary
s1 unfixed, no release (first upload):
  INFO posthog_cli::api::symbol_sets: Upload summary: 1 chunk(s) uploaded, 0 skipped (0 already present, 0 too large)
s2 unfixed, no release again (control):
  INFO posthog_cli::api::symbol_sets: Upload summary: 0 chunk(s) uploaded, 1 skipped (1 already present, 0 too large)
s3 unfixed, same code WITH release:
  INFO posthog_cli::api::symbol_sets: Upload summary: 1 chunk(s) uploaded, 0 skipped (0 already present, 0 too large)

# new binary
s1 fixed, no release (first upload):
  INFO posthog_cli::api::symbol_sets: Upload summary: 1 chunk(s) uploaded, 0 skipped (0 already present, 0 too large)
s2 fixed, no release again (control):
  INFO posthog_cli::api::symbol_sets: Upload summary: 0 chunk(s) uploaded, 1 skipped (1 already present, 0 too large)
s3 fixed, same code WITH release:
  INFO posthog_cli::api::symbol_sets: Upload summary: 1 chunk(s) uploaded, 0 skipped (0 already present, 0 too large)

Both binaries upload at s3. Through sourcemap process the restored map already differs between the two variants, which separates the hashes without this change. The collision needs the restored map to match, which the measurement above shows it does.

Automatic notifications

• Publish to changelog?

Docs update

None.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Written with Claude Code (Opus 5). Skills invoked: /writing-pr-descriptions.

A review on #91823 reported this. The test named above asserted the old behavior, so this PR changes what it claims.

The end-to-end run does not reproduce the stale map. The fix makes the hash depend on the snippet variant by construction, rather than through a difference in the restored map that happens to fall the right way.

[trunk-io]

😎 Merged successfully - details.

[github-actions]

🤖 CI report

✅ Trunk lane — non-backend lane

This PR is assigned to the non-backend lane. It does not run backend Python tests and may merge in parallel with PRs in other lanes.

[greptile-apps]

_{Reviews (1): Last reviewed commit: "fix(cli): hash the injected snippet vari..." | Re-trigger Greptile}

[Copilot]

Pull request overview

This PR fixes a correctness issue in the posthog-cli “event” release mode content hashing: previously, the content hash did not differentiate between the two injected snippet variants (chunk-id-only vs with-release), which can produce different uploaded sourcemaps for the same chunk id and lead to incorrect stack frame resolution.

Changes:

• Include the injected snippet variant (but not the specific release id) in the event-mode content_hash computation.
• Add a helper to detect whether a minified source contains the release-bearing snippet variant.
• Update/rename the regression test to assert the new expected hashing behavior, and add a changeset entry.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
cli/tests/sourcemap.rs	Updates the event-mode content-hash test to require snippet-variant sensitivity while remaining stable across different release ids.
cli/src/sourcemaps/source_pairs.rs	Extends event-mode content hashing to include a stable marker for the snippet variant.
cli/src/sourcemaps/content.rs	Adds has_release_snippet to detect the release-bearing injected snippet in the source.
cli/.sampo/changesets/event-mode-hash-snippet-variant.md	Records the patch-level change and rationale for release notes.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-09-01 13:39 UTC	Run
prod-us	✅ Deployed	2026-09-01 14:06 UTC	Run
prod-eu	✅ Deployed	2026-09-01 14:07 UTC	Run