feat(orb): wire Sentry into the Cloudflare Worker (central ORB broker) - #6036
Merged
Conversation
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6036 +/- ##
=======================================
Coverage 95.16% 95.17%
=======================================
Files 593 592 -1
Lines 46955 46960 +5
Branches 15006 15007 +1
=======================================
+ Hits 44685 44693 +8
+ Misses 1512 1511 -1
+ Partials 758 756 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Bundle ReportChanges will decrease total bundle size by 267 bytes (-0.01%) ⬇️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: loopover-uiAssets Changed:
|
Contributor
|
Caution 🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥 🛑 LoopOver review result - fixes requiredReview updated: 2026-07-15 07:26:59 UTC
🛑 Suggested Action - Manual Review Review summary Nits — 5 non-blocking
Why this is blocked
📋 Copy for AI agents — paste into your coding agentCI checks failing
Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://gittensory.aethereal.dev/docs/loopover-commands 🧪 Experimental — new and may change. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
The actual central ORB broker server -- the Cloudflare Worker at src/index.ts
/ src/api/routes.ts, handling every registration, token mint, and relay push/
pull request -- has had zero Sentry error tracking since it was built.
initSentry() has only ever been called from src/server.ts (the self-host Node
entrypoint); the Worker has no `.onError(` handler anywhere and no
Workers-compatible Sentry SDK dependency. Every ORB fix shipped earlier this
session was client-side (self-host); this is the corresponding server-side
gap, and by volume of traffic the larger one.
@sentry/hono + @sentry/cloudflare (peer dep) auto-capture via Hono's onError
by default, confirmed via the package's own README. nodejs_compat (needed for
AsyncLocalStorage) was already enabled.
The real complication: self-host's server.ts imports THIS Worker's own
exported `{fetch, queue}` object directly (`import worker from "./index"`)
and calls `worker.fetch(request, env, ctx)` for its own HTTP traffic --
server.ts synthesizes a Worker-shaped `env` by spreading `process.env`
specifically so it can reuse this handler byte-for-byte. Naming the new DSN
var the same as self-host's own SENTRY_DSN would have silently activated the
Cloudflare-only SDK inside a self-hoster's own Node process the moment they
set their own Sentry DSN. Fixed two ways: a distinctly-named
WORKER_SENTRY_DSN/WORKER_SENTRY_ENVIRONMENT (so there is no name collision to
begin with), AND gating the middleware's registration on
isCloudflareWorkerRuntime() -- checking navigator.userAgent === "Cloudflare-
Workers", Cloudflare's own documented idiom, verified true in a real workerd
isolate via test/workers and false under plain Node.
Registered as the first middleware in createApp() so it wraps every other
middleware and route. Scope: HTTP request handling only (every ORB endpoint).
The queue() handler's own top-level safety net is a separate, smaller
follow-up -- it dispatches ALL background job types, not just ORB's, and
@sentry/hono's onError integration doesn't cover it.
Codecov flagged the isCloudflareWorkerRuntime() TRUE branch as uncovered patch: it only genuinely executes inside a real Workers isolate, and test:coverage runs under plain Node (--pool=forks). The real coverage for this branch is test/workers/worker-runtime.test.ts, which runs under @cloudflare/vitest-pool-workers as a SEPARATE, non-coverage-instrumented step in test:ci -- Codecov has no visibility into it.
JSONbored
force-pushed
the
feat/worker-sentry-integration
branch
from
July 15, 2026 07:28
85915e2 to
9597167
Compare
4 tasks
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
1 participant
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.
Summary
src/index.ts/src/api/routes.ts, handling every registration, token mint, and relay push/pull request — has had zero Sentry error tracking since it was built.initSentry()has only ever been called fromsrc/server.ts(the self-host Node entrypoint); the Worker has no.onError(handler anywhere and no Workers-compatible Sentry SDK dependency. Every ORB fix shipped earlier this session was client-side (self-host); this is the corresponding server-side gap — and by request volume, the larger one.@sentry/hono+@sentry/cloudflare(peer dep) auto-capture via Hono'sonErrorby default, confirmed via the package's own README.nodejs_compat(needed forAsyncLocalStorage) was already enabled.server.tsimports THIS Worker's own exported{fetch, queue}object directly (import worker from "./index") and callsworker.fetch(request, env, ctx)for its own HTTP traffic —server.tssynthesizes a Worker-shapedenvby spreadingprocess.envspecifically so it can reuse this handler byte-for-byte. Naming the new DSN var the same as self-host's ownSENTRY_DSNwould have silently activated the Cloudflare-only SDK inside a self-hoster's own Node process the moment they set their own Sentry DSN.WORKER_SENTRY_DSN/WORKER_SENTRY_ENVIRONMENT(no name collision to begin with), and gating the middleware's registration onisCloudflareWorkerRuntime()— checkingnavigator.userAgent === "Cloudflare-Workers", Cloudflare's own documented idiom — verifiedtruein a realworkerdisolate viatest/workers/andfalseunder plain Node.createApp()so it wraps every other middleware and route.Scope
HTTP request handling only (every ORB endpoint). The
queue()handler's own top-level safety net is a separate, smaller follow-up — it dispatches ALL background job types, not just ORB's, and@sentry/hono'sonErrorintegration doesn't cover it.Test plan
test/unit/cloudflare-worker-runtime-detection.test.ts—isCloudflareWorkerRuntime()isfalseunder plain Node (self-host's real runtime).test/workers/worker-runtime.test.ts(realworkerdisolate via@cloudflare/vitest-pool-workers) —isCloudflareWorkerRuntime()istrue; existing routes still serve correctly with the middleware wrapping them; a request still succeeds whenWORKER_SENTRY_DSNis unset (registering the middleware must not itself break requests).npm run test:coverage(unsharded) — full local gate green, no regressions.npm run test:ci— green, re-verified after a rebase across 10 intervening commits.