fix(sentry): fail the build when the sourcemap upload fails #144

Merged

ullrich merged 1 commit from fail-build-on-sentry-upload-error into main 2026-09-11 14:10:51 +00:00

Conversation 0 Commits 1 Files changed 2 +30

ullrich commented 2026-09-11 13:44:30 +00:00

Owner

Copy link

Closes #5 — the follow-up that stops this class of silent rot.

Why the 401 hid for six weeks

sentry-vite-plugin treats release creation and sourcemap upload failures as recoverable. In build-plugin-manager.js:

handleRecoverableError(e, false)   // three call sites: release + upload

With throwByDefault === false and no errorHandler, it logs An error occurred. Couldn't finish all operations and the build succeeds. Every deploy stayed green while no sourcemap had ever reached Sentry. Production stack traces were unsymbolicated the whole time and nothing reported it — #5 was found only by reading a build log for an unrelated reason.

The change

An errorHandler that rethrows, in both apps:

errorHandler: (err) => {
  throw err;
},

The plugin calls the handler and propagates anything it throws, so the swallowed error becomes a build failure.

Verification

Ran a real build with a deliberately invalid token:

$ SENTRY_AUTH_TOKEN=sntryu_deliberatelyinvalid… pnpm --filter @trails-cool/planner build
Build failed with 1 error:
Error: Command failed: … sentry-cli releases new verify-fail-test
    sentry reported an error: Invalid token (http status: 401)
EXIT CODE: 1

On main that identical error exits 0. That is the whole bug, and the whole fix.

pnpm typecheck, pnpm lint and pnpm test pass. I did not run pnpm test:e2e locally — it needs the Docker stack and nothing here can reach it, since the plugin is disabled without a token. CI runs it.

Blast radius

Only builds carrying a token are affected. disable: !process.env.SENTRY_AUTH_TOKEN already turns the plugin off entirely without one, so local builds and CI are untouched and only CD can trip this.

The trade-off

A Sentry outage now blocks a deploy. That is deliberate and worth stating plainly, because it is a real cost: a transient upstream failure can hold up a release that is otherwise fine.

I think it is the right call — a deploy we cannot debug is worse than a deploy that waits, and #5 is six weeks of evidence for what the other default costs. If a blocked deploy ever becomes the bigger problem, the narrower fix is to rethrow only when an env var like SENTRY_UPLOAD_REQUIRED is set, and set it in cd-apps.yml alone. Say so and I will do it that way instead.

🤖 Generated with Claude Code

Closes #5 — the follow-up that stops this class of silent rot. ## Why the 401 hid for six weeks `sentry-vite-plugin` treats release creation and sourcemap upload failures as *recoverable*. In `build-plugin-manager.js`: ```js handleRecoverableError(e, false) // three call sites: release + upload ``` With `throwByDefault === false` and no `errorHandler`, it logs `An error occurred. Couldn't finish all operations` and the build succeeds. Every deploy stayed green while no sourcemap had ever reached Sentry. Production stack traces were unsymbolicated the whole time and nothing reported it — #5 was found only by reading a build log for an unrelated reason. ## The change An `errorHandler` that rethrows, in both apps: ```ts errorHandler: (err) => { throw err; }, ``` The plugin calls the handler and propagates anything it throws, so the swallowed error becomes a build failure. ## Verification Ran a real build with a deliberately invalid token: ``` $ SENTRY_AUTH_TOKEN=sntryu_deliberatelyinvalid… pnpm --filter @trails-cool/planner build Build failed with 1 error: Error: Command failed: … sentry-cli releases new verify-fail-test sentry reported an error: Invalid token (http status: 401) EXIT CODE: 1 ``` On `main` that identical error exits **0**. That is the whole bug, and the whole fix. `pnpm typecheck`, `pnpm lint` and `pnpm test` pass. I did not run `pnpm test:e2e` locally — it needs the Docker stack and nothing here can reach it, since the plugin is disabled without a token. CI runs it. ## Blast radius Only builds carrying a token are affected. `disable: !process.env.SENTRY_AUTH_TOKEN` already turns the plugin off entirely without one, so local builds and CI are untouched and only CD can trip this. ## The trade-off A Sentry outage now blocks a deploy. That is deliberate and worth stating plainly, because it is a real cost: a transient upstream failure can hold up a release that is otherwise fine. I think it is the right call — a deploy we cannot debug is worse than a deploy that waits, and #5 is six weeks of evidence for what the other default costs. If a blocked deploy ever becomes the bigger problem, the narrower fix is to rethrow only when an env var like `SENTRY_UPLOAD_REQUIRED` is set, and set it in `cd-apps.yml` alone. Say so and I will do it that way instead. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

ullrich added 1 commit 2026-09-11 13:44:30 +00:00

fix(sentry): fail the build when the sourcemap upload fails ... 10326e468d

Release creation and sourcemap upload failures are "recoverable" to
sentry-vite-plugin: `handleRecoverableError(e, false)` logs `An error
occurred. Couldn't finish all operations` and lets the build succeed.

That is the mechanism behind #5. For six weeks every deploy was green while
no sourcemap had ever reached Sentry, so production stack traces were
unsymbolicated and nothing said so. The upload was only found by reading a
build log for an unrelated reason.

Supplying an `errorHandler` that rethrows converts the swallowed error into a
build failure. Verified locally: with a deliberately invalid token,
`pnpm --filter @trails-cool/planner build` now exits 1 with `Build failed
with 1 error`; on main the same error exits 0.

Only builds that carry a token are affected — `disable:
!process.env.SENTRY_AUTH_TOKEN` turns the plugin off entirely without one, so
local and CI builds are untouched and only CD can trip this.

The trade-off is deliberate: a Sentry outage now blocks a deploy. A deploy we
cannot debug is worse than a deploy that waits.

Closes #5

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ullrich merged commit 6c715f17ce into main 2026-09-11 14:10:51 +00:00

ullrich deleted branch fail-build-on-sentry-upload-error 2026-09-11 14:10:51 +00:00

ullrich referenced this pull request from a commit 2026-09-11 14:10:53 +00:00

Merge pull request 'fix(sentry): fail the build when the sourcemap upload fails' (#144) from fail-build-on-sentry-upload-error into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

dependencies

Dependency updates raised by Renovate (renovate.json5 labels)

  

major

Major version bump — always needs human review, never auto-merged

  

security-pin

Touches a pnpm.overrides CVE remediation pin, not an ordinary dependency

No labels

dependencies

major

security-pin

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

trails-cool/trails!144

No description provided.