feat(cloudflare): Add Spotlight integration for local dev event forwarding#22490
feat(cloudflare): Add Spotlight integration for local dev event forwarding#22490MathurAditya724 wants to merge 6 commits into
Conversation
…rding Add a fetch-based spotlightIntegration to @sentry/cloudflare that mirrors envelopes to a local Spotlight sidecar during development. This closes the gap where Cloudflare Workers was the only server SDK without Spotlight support. - New integration at src/integrations/spotlight.ts using fetch + suppressTracing - Wire in sdk.ts init() with rollup-include-development-only markers (stripped from prod builds) - Read SENTRY_SPOTLIGHT from CF env binding in getFinalOptions (boolean or URL) - Export spotlightIntegration from package index - Full test coverage (integration tests + options tests)
CloudflareOptions extends Options (CoreOptions) which does not include ServerRuntimeOptions where spotlight is declared. Add the property directly to BaseCloudflareOptions so TypeScript resolves it correctly.
size-limit report 📦
|
- Fix spotlight precedence to match node-core's getSpotlightConfig: spotlight: true + env URL → uses env URL (not bare true) - Fix accidental extra-space indent on instrumentPrototypeMethods - Add tests: spotlight:true + env URL, 4xx/5xx status handling
…ght wiring The rollup-include-development-only markers only strip content when the package build uses splitDevProd (only @sentry/browser does). The Cloudflare package uses a single build without that plugin, so the markers were inert and misleading. Match the node-core pattern: guard spotlight wiring with the runtime 'if (options.spotlight)' check, which is falsy in production.
I had a quick look through the code so I might have missed it but how does
This is not true. The Node SDK specifically ship dev/prod output and strips this from production builds. |
I was wrong, we only do this in the browser: sentry-javascript/packages/browser/src/sdk.ts Lines 103 to 111 in 532ac86 |
Ya, I just went through and we only have this in the browser. @timfish if I'm not mistaken we only have to add |
Summary
Add a fetch-based
spotlightIntegrationto@sentry/cloudflarethat mirrors Sentry envelopes to a local Spotlight sidecar during development. Cloudflare Workers was the only server SDK without Spotlight support.What this enables
spotlight: trueinSentry.init()(orwithSentry) forwards all envelopes (errors, transactions, logs, AI spans) tohttp://localhost:8969/streamSENTRY_SPOTLIGHTwrangler env binding (boolean or custom URL) for zero-code-change enablementsentry local servefrom the Sentry CLI for a complete local dev experienceChanges
src/integrations/spotlight.ts— usesfetchwithsuppressTracing(CF instruments outbound fetch), consumes response body (Workers requirement), disables after >3 failuressdk.ts— wire integration ininit()behind a runtimeif (options.spotlight)guard (matches the node-core pattern)options.ts— readSENTRY_SPOTLIGHTfrom CF env binding with the same precedence as node-core'sgetSpotlightConfig(user option > env boolean > env URL)client.ts— addspotlight?: boolean | stringtoBaseCloudflareOptions(CloudflareOptions extends Options/CoreOptions, which does not includeServerRuntimeOptionswherespotlightnormally lives)index.ts— exportspotlightIntegrationWhy fetch, not node:http
Cloudflare Workers don't have
node:http. The integration mirrors the browser SDK's fetch-based approach but addssuppressTracing(like Node) since CF'sfetchIntegrationinstruments all outbound fetch, and drains the response body (Workers-specific requirement, same as the CF transport).Production behavior
Spotlight forwarding only activates when
options.spotlightis truthy, which is falsy in production by default — identical to how@sentry/node,@sentry/bun, and all other server SDKs ship the spotlight integration. Each forwarded envelope counts as a Worker subrequest (cap 50 free / 1000 paid), documented in the integration JSDoc; keep it disabled in production.