feat(cli): add event release mode to the hermes commands - #87660
Merged
Conversation
|
😎 Merged successfully - details. |
Contributor
🤖 CI report✅ Trunk lane — non-backend laneThis 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. |
A Hermes chunk id is derived from bundle content, so two releases that ship the same JavaScript land on one symbol set. In symbol-set mode the release lives on that symbol set, so the second release either collides or reports the first one's release. `--release-mode event` on `hermes clone` and `hermes upload` leaves the maps release-independent. The release row is still created, so the server can resolve an event's $app_namespace / $app_version / $app_build onto it, the way it already does for iOS dSYMs and Android mappings. Nothing has to be injected into the app in exchange. `hermes inject` no longer rejects event mode. It injects content-addressed chunk ids and embeds no release id, because a Hermes bytecode bundle has nothing that reads the global back out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The comment claimed that skipping the conflict would keep the old release bound and make exceptions report it. That is wrong. A symbol set's release lives in posthog_errortrackingsymbolset.release_id, which cymbal joins on, and event mode sends no release id, so the server never touches that column. Neither force nor skip changes the binding. The real reason is narrower. A hermes chunk id comes from the bundle content and the release id sits inside the uploaded map, so the build that changes release mode sends the same id with different bytes and the server refuses it. Overwriting is what lets that build pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ablaszkiewicz
force-pushed
the
ab/feat/hermes-event-release-mode
branch
from
August 24, 2026 13:48
cda3fa3 to
125b6df
Compare
Contributor
🦔 ReviewHog reviewed this pull requestNothing worth raising this time, so here's a calming picture instead:
|
ablaszkiewicz
marked this pull request as ready for review
August 24, 2026 18:32
pr-assigner-resolver-posthog
Bot
requested review from
a team,
cat-ph and
hpouillot
August 24, 2026 18:33
Contributor
Prompt To Fix All With AI### Issue 1
cli/src/sourcemaps/hermes/upload.rs:67-68
**Build coordinate escapes validation**
When event mode receives an explicit release name and version but no `--build`, this condition emits no warning and creates a bare-version release that does not match mobile events carrying `$app_build`, causing those exceptions to report no release.
```suggestion
if *release_mode == ReleaseMode::Event
&& (release.name.is_none() || release.version.is_none() || release.build.is_none())
{
```
### Issue 2
cli/src/sourcemaps/hermes/clone.rs:27-40
**Hermes workflow documentation is missing**
The CLI now exposes event release mode across Hermes clone, upload, and inject, but the PR adds only a release changeset rather than durable setup and migration documentation under `docs/`, leaving users without guidance for coordinating the mode and mobile release coordinates.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "chore(cli): correct why hermes event mod..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
The server packs the build number into the version it keys a release on, so a release created without --build matches no event carrying $app_build, and the exception reports no release. The warning already named --build; the condition did not check it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ablaszkiewicz
added a commit
to PostHog/posthog-js
that referenced
this pull request
Aug 26, 2026
An older posthog-cli rejects --release-mode with a bare argument-parser error. posthog-xcode.sh and posthog.gradle now read the CLI version first and name the upgrade. The floor is a placeholder until PostHog/posthog#87660 releases, and until then event mode fails with a message that says so. POSTHOG_SKIP_CLI_VERSION_CHECK=1 allows a CLI built from source. Also guards --posthog-release-mode against a missing value, corrects the documented floors (posthog-cli 0.13.0 for the Android mapping upload, posthog-ios 3.69.1 for dSYMs), and adds a test that holds the release mode lists in posthog-xcode.sh, posthog.gradle and the dSYM phase to POSTHOG_RELEASE_MODES. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ablaszkiewicz
added a commit
to PostHog/posthog-js
that referenced
this pull request
Aug 26, 2026
An older posthog-cli rejects --release-mode with a bare argument-parser error. posthog-xcode.sh and posthog.gradle now read the CLI version first and name the upgrade. The floor is a placeholder until PostHog/posthog#87660 releases, and until then event mode fails with a message that says so. POSTHOG_SKIP_CLI_VERSION_CHECK=1 allows a CLI built from source. Also guards --posthog-release-mode against a missing value, corrects the documented floors (posthog-cli 0.13.0 for the Android mapping upload, posthog-ios 3.69.1 for dSYMs), and adds a test that holds the release mode lists in posthog-xcode.sh, posthog.gradle and the dSYM phase to POSTHOG_RELEASE_MODES. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
hpouillot
approved these changes
Aug 26, 2026
cat-ph
approved these changes
Aug 26, 2026
ablaszkiewicz
added a commit
to PostHog/posthog-js
that referenced
this pull request
Aug 27, 2026
posthog-cli 0.16.0 (PostHog/posthog#87660) carries --release-mode on the hermes commands, so the placeholder floor that refused event mode outright becomes a real version check in posthog-xcode.sh and posthog.gradle. The changeset and the expo plugin docs name the minimum, and the wrapper tests drop the floor substitution now that the shipped floor is real. A new test holds the two floors to the same version. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
Tests
I ran tests covering all use cases. Usual scenario is:
Tested that on:
ios (legacy)
First run
posthog-cli, React Native source maps
posthog-cli, dSYMs (414 unreadable-source warnings elided)
JavaScript exception:
Native crash:
Second run (with changes)
posthog-cli, React Native source maps
posthog-cli, dSYMs (414 unreadable-source warnings elided)
Third run (no change, new release)
posthog-cli, React Native source maps
The build fails here, so the app is never installed and never reports anything. That is why this run
has no screenshots.
ios (new release mode)
First run
posthog-cli, React Native source maps
posthog-cli, dSYMs (414 unreadable-source warnings elided)
JavaScript exception:
Native crash:
Second run (with changes)
posthog-cli, React Native source maps
posthog-cli, dSYMs (414 unreadable-source warnings elided)
Third run (no change, new release)
posthog-cli, React Native source maps
posthog-cli, dSYMs (414 unreadable-source warnings elided)
JavaScript exception:
Native crash:
android (legacy)
First run
posthog-cli, React Native source maps
posthog-cli, R8 mapping
JavaScript exception:
Native crash:
Second run (with changes)
posthog-cli, React Native source maps
Third run (no change, new release)
posthog-cli, React Native source maps
The build fails here, so the app is never installed and never reports anything. That is why this run
has no screenshots.
android (new release mode)
First run
posthog-cli, React Native source maps
posthog-cli, R8 mapping
JavaScript exception:
Native crash:
Second run (with changes)
posthog-cli, React Native source maps
Third run (no change, new release)
posthog-cli, React Native source maps
posthog-cli, R8 mapping
JavaScript exception:
Native crash: