Environment
Steps to Reproduce
export SENTRY_AUTH_TOKEN=... SENTRY_ORG=... SENTRY_PROJECT=...sentry proguard upload mapping.txt --log-level debug, with any R8/ProGuard mapping file.
Expected Result
The mapping assembles and a ProGuard DIF is created for the computed UUID, as legacy sentry-cli proguard upload does for the same file.
Actual Result
Every HTTP call returns 200, then assembly fails:
$ sentry proguard upload mapping.txt --log-level debug
[debug] [http] GET /api/0/organizations/<org>/chunk-upload/ → 200
[debug] [http] POST /api/0/projects/<org>/<project>/files/difs/assemble/ → 200
Error: ProGuard mapping assembly failed
Endpoint: projects/<org>/<project>/files/difs/assemble/
Invalid debug information file: unsupported object file format
This happens 100% of the time, for every mapping — no ProGuard DIF is ever created, so nothing symbolicates. Because every request is a 200 and the failure only appears inside the per-checksum detail field of the assemble response body, it presents as an auth, org/project, or corrupt-mapping problem rather than a payload bug.
Root cause. packages/cli/src/lib/api/proguard.ts builds the assemble body with:
name: `proguard/${cm.mapping.uuid}.txt`,ProGuard/R8 mappings are plain text with no magic bytes, so Sentry identifies them purely by the /proguard/ prefix in the request name (sentry/src/sentry/models/debugfile.py):
_proguard_file_re = re.compile(r"/proguard/(?:mapping-)?(.*?)\.txt$")
Without the leading slash there is no match, ProGuard detection is skipped, and the file falls through to generic native-object parsing — Archive.open() on a text file raises, which surfaces as the error above. Legacy sentry-cli sends /proguard/{uuid}.txt (src/utils/proguard/mapping.rs), which is why the same mappings uploaded fine before switching CLIs.
Fix (one character) in #1372.
Environment
sentryCLI0.40.0and0.41.0. The offending line is unchanged in0.42.2and onmain, so every version sinceproguard uploadwas added in feat(proguard): add 'proguard upload' command (chunk-upload of R8/ProGuard mappings) #1074 is affected.SENTRY_AUTH_TOKEN/SENTRY_ORG/SENTRY_PROJECT.sentry-linux-x64(CI) andsentry-darwin-arm64.Steps to Reproduce
export SENTRY_AUTH_TOKEN=... SENTRY_ORG=... SENTRY_PROJECT=...sentry proguard upload mapping.txt --log-level debug, with any R8/ProGuard mapping file.Expected Result
The mapping assembles and a ProGuard DIF is created for the computed UUID, as legacy
sentry-cli proguard uploaddoes for the same file.Actual Result
Every HTTP call returns
200, then assembly fails:This happens 100% of the time, for every mapping — no ProGuard DIF is ever created, so nothing symbolicates. Because every request is a
200and the failure only appears inside the per-checksumdetailfield of the assemble response body, it presents as an auth, org/project, or corrupt-mapping problem rather than a payload bug.Root cause.
packages/cli/src/lib/api/proguard.tsbuilds the assemble body with:ProGuard/R8 mappings are plain text with no magic bytes, so Sentry identifies them purely by the
/proguard/prefix in the requestname(sentry/src/sentry/models/debugfile.py):Without the leading slash there is no match, ProGuard detection is skipped, and the file falls through to generic native-object parsing —
Archive.open()on a text file raises, which surfaces as the error above. Legacysentry-clisends/proguard/{uuid}.txt(src/utils/proguard/mapping.rs), which is why the same mappings uploaded fine before switching CLIs.Fix (one character) in #1372.