Summary
POST /v1/orb/token (the Orb token-broker exchange) returns a bare HTTP 500 — 95 events over 10+ days.
Evidence (Sentry)
GITTENSORY-J — orb_broker_unavailable: Orb broker token exchange failed (500). First seen 2026-06-29, last seen 2026-07-09.
Root cause — already investigated, this is NOT a simple "wrap in try-catch" fix
Sentry Seer's summary ("Wrap the entire /v1/orb/token handler in a top-level try-catch so unhandled stream/DB errors return 503 instead of a framework 500") does not match the current code and must not be blindly applied:
- The handler (
src/api/routes.ts:3311) already wraps its brokerOrbToken call in try/catch, returning 503 on any thrown error.
readOrbRelayRegisterBody (src/orb/relay.ts:175), the one call in this handler made before that try/catch, was already hardened for exactly this failure mode in commit 65de78ec6e7bf5350e217bc3aa4c62dda9911c88 (2026-07-05, tagged #orb-broker-500 in its own doc comment) — its own comment literally describes fixing "a bare framework 500 instead of the route's own clean 4xx/503 JSON error response."- That fix commit is confirmed to be an ancestor of every commit that has run on the self-host box since (verified via
git merge-base --is-ancestor).
- Yet this Sentry issue's last occurrence (2026-07-09) is 4 days after that fix was live in production.
This means the 2026-06-29–07-03 events are likely the original, already-understood bug. The 2026-07-05–07-09 events (after the fix deployed) are either a regression, an incomplete fix (a different unhandled-throw path in brokerOrbToken itself, or in Hono's own routing/middleware layer before this handler is even reached), or evidence the fix's deploy didn't reach production as early as the commit timestamp suggests. Needs to be distinguished by re-checking Sentry's event timestamps against exact deploy windows, not assumed.
Requirements
- Confirm precisely which events (by timestamp) occurred before vs. after the 07-05 fix actually went live on the box.
- If post-fix events remain: find the actual remaining unhandled-throw path (check
brokerOrbToken itself and anything Hono-level ahead of this route) rather than re-applying the same already-shipped fix.
- Do not just re-wrap the outer handler again without first confirming that isn't already sufficient.
Deliverables
Summary
POST /v1/orb/token(the Orb token-broker exchange) returns a bare HTTP 500 — 95 events over 10+ days.Evidence (Sentry)
GITTENSORY-J —
orb_broker_unavailable: Orb broker token exchange failed (500).First seen 2026-06-29, last seen 2026-07-09.Root cause — already investigated, this is NOT a simple "wrap in try-catch" fix
Sentry Seer's summary ("Wrap the entire
/v1/orb/tokenhandler in a top-level try-catch so unhandled stream/DB errors return 503 instead of a framework 500") does not match the current code and must not be blindly applied:src/api/routes.ts:3311) already wraps itsbrokerOrbTokencall in try/catch, returning 503 on any thrown error.readOrbRelayRegisterBody(src/orb/relay.ts:175), the one call in this handler made before that try/catch, was already hardened for exactly this failure mode in commit65de78ec6e7bf5350e217bc3aa4c62dda9911c88(2026-07-05, tagged#orb-broker-500in its own doc comment) — its own comment literally describes fixing "a bare framework 500 instead of the route's own clean 4xx/503 JSON error response."git merge-base --is-ancestor).This means the 2026-06-29–07-03 events are likely the original, already-understood bug. The 2026-07-05–07-09 events (after the fix deployed) are either a regression, an incomplete fix (a different unhandled-throw path in
brokerOrbTokenitself, or in Hono's own routing/middleware layer before this handler is even reached), or evidence the fix's deploy didn't reach production as early as the commit timestamp suggests. Needs to be distinguished by re-checking Sentry's event timestamps against exact deploy windows, not assumed.Requirements
brokerOrbTokenitself and anything Hono-level ahead of this route) rather than re-applying the same already-shipped fix.Deliverables