You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SvelteKit Demo + Sentry wizard: Sentry.diagnoseSdkConnectivity() bad request (is this actually expected?) #16226
git clone git@github.com:kt-npm-modules/svelte-adapter-azure-swa.git
cd svelte-adapter-azure-swa
npm ci:all
cd tests/demo
npm run build
npm run preview
Click through Home, About, Sverdle, and "Sentry Example"
Expected Result
I suppose no error should happen for calling this method created by wizard
changed the title [-]SvelteKit Demo + Sentry wizard: Sentry.diagnoseSdkConnectivity() bad request + uncatchable exception[/-][+]SvelteKit Demo + Sentry wizard: Sentry.diagnoseSdkConnectivity() bad request (is this actually expected?)[/+]on May 7, 2025
This request failing is more or less intended. The diagnoseSdkConnectivity() function is simulating a request to the Sentry ingestion endpoint to figure out whether Sentry is reachable and more importantly whether there are any ad blockers active in the browser. We're not sending an actual payload to Sentry, we're just testing for connectivity - which would be blocked in the case of ad blockers. Does the failed request show up in the browser? Yes. Does it matter? No.
It obviously confused you so I am thinking we should maybe do something about it.
My main idea would be to have some rule in our infra that always 200s for a particular set of org/project/client-key combination.
current state: I raised internally that we may want to have a hardcoded rule in nginx that always returns a 200 with a specific message for exactly POST https://o1337.ingest.sentry.io/api/1337/envelope/?sentry_version=1337&sentry_key=1337&sentry_client=sentry.javascript.browser%2F1.33.7
Hey @ktarmyshov quick update: I opened and merged #16840 to avoid getting the 400 response. Coincidentally, this also came up in #16818 so I think it was a valuable fix. The fix should go out with the next SDK release sometime later this week.
Activity
[-]SvelteKit Demo + Sentry wizard: Sentry.diagnoseSdkConnectivity() bad request + uncatchable exception[/-][+]SvelteKit Demo + Sentry wizard: Sentry.diagnoseSdkConnectivity() bad request (is this actually expected?)[/+]lforst commentedon May 8, 2025
This request failing is more or less intended. The
diagnoseSdkConnectivity()function is simulating a request to the Sentry ingestion endpoint to figure out whether Sentry is reachable and more importantly whether there are any ad blockers active in the browser. We're not sending an actual payload to Sentry, we're just testing for connectivity - which would be blocked in the case of ad blockers. Does the failed request show up in the browser? Yes. Does it matter? No.It obviously confused you so I am thinking we should maybe do something about it.
My main idea would be to have some rule in our infra that always 200s for a particular set of org/project/client-key combination.
ktarmyshov commentedon May 8, 2025
Just a comment to sentry sample page from wizard and in document will do - expect bad request but it's fine ignore.
lol wasted time 😂🤦 of two or more ppl. No need for rules.
You are right, I was thinking smth wrong with my setup.
lforst commentedon May 8, 2025
Gonna reopen cause I think this is indeed confusing and we can fix it.
lforst commentedon May 9, 2025
current state: I raised internally that we may want to have a hardcoded rule in nginx that always returns a 200 with a specific message for exactly
POST https://o1337.ingest.sentry.io/api/1337/envelope/?sentry_version=1337&sentry_key=1337&sentry_client=sentry.javascript.browser%2F1.33.7fix(browser): Avoid 4xx response for succesful `diagnoseSdkConnectivi…
Lms24 commentedon Jul 8, 2025
Hey @ktarmyshov quick update: I opened and merged #16840 to avoid getting the 400 response. Coincidentally, this also came up in #16818 so I think it was a valuable fix. The fix should go out with the next SDK release sometime later this week.
ktarmyshov commentedon Jul 8, 2025
@Lms24 thank you!
github-actions commentedon Jul 9, 2025
A PR closing this issue has just been released 🚀
This issue was referenced by PR #16840, which was included in the 9.36.0 release.