Repository navigation
Setup instructions for Cloudflare workers and Sveltekit lead to broken installation #16818
Closed as duplicate
Description
Is there an existing issue for this?
- I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- I have reviewed the documentation https://docs.sentry.io/
- I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/cloudflare
SDK Version
9.35.0
Framework Version
Sveltekit 2.16.0
Link to Sentry event
No response
Reproduction Example/SDK Setup
https://github.com/RaniSputnik/sentry-issues/tree/enable-not-a-function
Steps to Reproduce
- Follow the getting started guide for a new Sveltekit app, including using the Cloudflare adapter.
- Run
npx @sentry/wizard@latest -i sveltekit - Follow Cloudflare + Sveltekit specific setup instructions
- Add a minimal
wrangler.toml:
name = "some-project-name"
main = ".svelte-kit/cloudflare/_worker.js"
compatibility_date = "2025-01-01"
compatibility_flags = ["nodejs_compat"]
version_metadata = { binding = "CF_VERSION_METADATA" }
[assets]
binding = "assets"
directory = ".svelte-kit/cloudflare"
[observability]
enabled = true
head_sampling_rate = 1
Expected Result
My setup is functional. I can use the Sentry test error page to trigger client side + server side errors.
Actual Result
Symptom 1
I get intermittent 500's when trying to load the page with the following error in the logs:
TypeError: this.enable is not a function
at new InstrumentationBase (_worker.js:17457:16)
at new SentryHttpInstrumentation (_worker.js:28603:9)
at _worker.js:28871:16
at Object.assign.id (_worker.js:20577:31)
at Object.setupOnce (_worker.js:28892:11)
at setupIntegration (_worker.js:5979:17)
at _worker.js:5960:7
at Array.forEach (<anonymous>)
at setupIntegrations (_worker.js:5958:16)
at NodeClient._setupIntegrations (_worker.js:6576:30)
Symptom 2
I see 400's in the browser on every page load when posting to https://o447951.ingest.sentry.io:
{"detail":"bad sentry DSN public key","causes":["invalid project key"]}
Symptom 3
The Sentry example page raises and error client side and posts to an API route that also errors. It should produce two errors, one from the client and one from the server. Client errors are being reported, server errors are not:
Metadata
Metadata
Assignees
Projects
- Status
Activity
[-]Error `this.enable is not a function` using Cloudflare workers and Sveltekit[/-][+]Setup instructions for Cloudflare workers and Sveltekit lead to broken installation[/+]RaniSputnik commentedon Jul 6, 2025
I've just seen this page on Sveltekit adapter compatibility.
That seems to contradict the documentation which offers a setup guide for Cloudflare and SvelteKit without caveats. Now it's unclear to me what Sentry's position is.
Could you please clarify: Is the Cloudflare adapter for SvelteKit officially supported?
I think once that's answered, either the
@sentry/sveltekitreadme should be updated, or the documentation should have a caveat that this isn't an officially supported adapter.Cheers! ✌️
mydea commentedon Jul 7, 2025
Hello, one question: Are you getting this when running it locally, or when deployed to cloudflare? We do officially support this, but there may be some kinks to iron out.
I've seen similar things when running this locally with wrangler 3, in that case it got fixed by updating to wrangler 4. Also it was just an issue when running locally. Could this be the same problem
RaniSputnik commentedon Jul 7, 2025
Hi @mydea
I only see these issues when running on Cloudflare. When I run
npm run devlocally, both issues are successfully reported to Sentry. I also don't see any errors (other than the one's thrown by the Sentry example) when running locally.I can also confirm my example uses Wrangler 4.x:
Thanks for confirming, I can open a separate issue to improve that documentation.
Lms24 commentedon Jul 7, 2025
Hey, I'll take a look at this issue in a minute.
Yes, the readme is outdated. Will update it.
4 remaining items
Lms24 commentedon Jul 7, 2025
@RaniSputnik thanks a lot for the reproduction btw! I managed to deploy your repro on my CF account and can reproduce the same error.
Yup, agreed, this seems to be the problem here. Taking a look if we incorrectly import something somewhere. Otherwise, this could also be related to a sveltekit (adapter) build change. I definitely had SvelteKit + CloudFlare Adapter + Cloudflare working before in test apps, so chances are something in this chain recently made a change.
doc(sveltekit): Streamline Readme and remove outdated information (#1…
RaniSputnik commentedon Jul 8, 2025
Okay, more data incoming!
I've tried reproducing this issue with a few different versions of the libraries involved:
_worker.jsas a static asset)Error: Bundling with esbuild failed with 64 errorsError: Bundling with esbuild failed with 27 errorsthis.enable is not a functionerrorsWhen comparing the build output from 2 and 5 I get the following in diff:
Looks like our theory was right, a change to which packages are marked as external would explain what's going on here. The build environment is node and so the wrong index file from the Sentry package is being included.
I don't know how that
noExternallist is built, but given that all I changed between runs 2 and 5 was the@sveltejs/kit, I think it's safe to say that this issue is upstream of the Sentry SDK.Great so we close this issue then?
I'm not sure. Even though downgrading the
@sveltejs/kitpackage did fix the runtime server errors, it didn't fix the 400 that I was seeing in the browser{"detail":"bad sentry DSN public key","causes":["invalid project key"]}@Lms24 I'd be interested to know whether you also see this error or if that's a me problem 🤔
That said, the error reporting does seem to be working in spite of the 400:
Lms24 commentedon Jul 8, 2025
Thanks so much for digging into this further! It kinda confirms a suspicion I had yesterday, since I knew they made some build changes w.r.t externalizing packages. Need to dig up the PR and also to narrow it down further to the last good/first bad version. Then I'll reach out to the svelte team for advice/assistance.
I'm fairly sure this is coming from another request that we make on the
sentry-example-pageroute: We send an initial request to Sentry (you can see theSentry.diagnoseSdkConnectivity()call in the page's code. In this request, we currently still include a non-existing org id and it's public key which produces this 400 response. You're not the only one who got confused by this (see #16226) so I opened a PR today to fix this: #16840. So, contrary to the response message, this has nothing to do with your DSN but much rather with the URL we make a request to in the example page.So for now, it's safe to ignore the 400 response and probably best to stay on the working kit version (2) until we figured out how to deal with the sveltekit change.
Lms24 commentedon Jul 8, 2025
I'm realizing this seems very much related to #16613
Lms24 commentedon Jul 8, 2025
@RaniSputnik I could fix your reproduction with the most recent SvelteKit version by setting
in the
vite.config.tsfile, as suggested in sveltejs/kit#13869 (comment)Setting
@sentry/sveltekitas external should be fine, since it will later be bundled in by the cloudflare adapter anyway, just this time with theworkerexports and hence no@sentry/nodecode ends up in the bundle.So it does indeed seem to be the same issue as reported in #16613. I'll crosslink this issue there but close it to avoid dupliation.
initCloudflareSentryHandlethrows error when building/deploying to cloudflare pages #16613Downgrade Sveltekit to 2.17.1