Closed smeubank closed 1 year ago
Hi the team 👋
In my dashboard, I have a lot of these: POST null
It's probably because I'm using GraphQL.
On the other side, as I want detailed diagnostics on GraphQL, I'm using @envelop/sentry
to log more things and it's working well.
I have the feeling that POST null
is redundant with the detailed logs that I have. How to not send them?
A bit similar,
Maybe sor URL can have a custom tracesSampleRate
? To have less of:
Thx for your help.
Maybe it helps others.
In Sentry.init
, you can play with beforeSendTransaction
to filter out things.
Example:
beforeSendTransaction(event) {
// server provider is pinging the server non stop. Let's do a special treatmeant.
if (event.transaction === 'GET /api/healthz') {
// let's skip 99% of logs
if (Math.random() > 0.01) {
return null
}
}
// '@envelop/sentry' plugin is logging the transaction with a lot of GraphQL details.
// Let's not log the default "POST null"
else if (event.transaction === 'POST null') {
return null
}
return event
},
I'm not sure that event.transaction === 'POST null'
is very robust. I would like to specify the URL to make sure I don't filter out too many things, but I didn't find the URL that look like .../graphql
.
Maybe it's something that you could embed somewhere on all POST event?
I'm seeing something similar. In my case, these are mostly 302's or 404's, all server-side. The 404's are a mixed bag of bot spam along with requests for *.js.map files that fire when you open the browser's devtools (I delete sourcemap when before deploying).
The transaction name Get Null
could be the one set here, but tbh I'm not sure what/if there's anything to be done here. Maybe we can log the pathname to be able to identify them? The 302's in my example are especially difficult to track down so having a pathname associated would help in that regard.
Also, would be nice to bump some dep as I get deprecated sourcemap-codec@1.4.8
on pnpm i
dependencies:
@sentry/sveltekit 7.52.1
└─┬ @sentry/svelte 7.52.1
└─┬ magic-string 0.26.7
└── sourcemap-codec 1.4.8
Thx
RE GET null
server transactions
EDIT: Extracted this to a separate issue in #8199. Will link to your replies but let's please continue over there.
To everyone following this thread: If you come across bugs or have specific requests, please open a new issue instead of replying here, thanks! This helps us triaging and keeping a better overview, thanks :)
Updating form 7.49.0 -> 7.50.0 (or any thereafter) results in this error when I run vite dev
:
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
TypeError: response.headers is not iterable
at setResponse (file:///project/node_modules/.pnpm/@sveltejs+kit@1.20.2_svelte@3.59.1_vite@4.3.9/node_modules/@sveltejs/kit/src/exports/node/index.js:119:38)
at file:///project/node_modules/.pnpm/@sveltejs+kit@1.20.2_svelte@3.59.1_vite@4.3.9/node_modules/@sveltejs/kit/src/exports/vite/dev/index.js:520:6
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
It also fails when run in production mode (e.g. Vercel). I'm puzzled no one else has seen this as my project isn't very different than most simple SvelteKit projects. I updated to the latest versions of Vite (4.3.0) and SvelteKit (1.20.2) but to no avail.
@skylar (sorry for getting back to you only now, I was ooo) would you mind opening an issue with a minimal reproduction for this? It's also the first time that I'm hearing about this.
Is there a timeline for supporting the Vercel edge runtime? Currently getting this error when I try to build:
> Using @sveltejs/adapter-vercel
✘ [ERROR] Could not resolve "$app/stores"
../../node_modules/.pnpm/@sentry+sveltekit@7.60.0_@sveltejs+kit@1.15.2_svelte@3.55.1/node_modules/@sentry/sveltekit/esm/client/router.js:3:33:
3 │ import { page, navigating } from '$app/stores';
╵ ~~~~~~~~~~~~~
You can mark the path "$app/stores" as external to exclude it from the bundle, which will remove this error.
error during build:
Error: Build failed with 1 error:
../../node_modules/.pnpm/@sentry+sveltekit@7.60.0_@sveltejs+kit@1.15.2_svelte@3.55.1/node_modules/@sentry/sveltekit/esm/client/router.js:3:33: ERROR: Could not resolve "$app/stores"
at failureErrorWithLog (<REPO PATH>/node_modules/.pnpm/esbuild@0.18.11/node_modules/esbuild/lib/main.js:1639:15)
at <REPO PATH>/node_modules/.pnpm/esbuild@0.18.11/node_modules/esbuild/lib/main.js:1051:25
at <REPO PATH>/node_modules/.pnpm/esbuild@0.18.11/node_modules/esbuild/lib/main.js:996:52
at buildResponseToResult (<REPO PATH>/node_modules/.pnpm/esbuild@0.18.11/node_modules/esbuild/lib/main.js:1049:7)
at <REPO PATH>/node_modules/.pnpm/esbuild@0.18.11/node_modules/esbuild/lib/main.js:1078:16
at responseCallbacks.<computed> (<REPO PATH>/node_modules/.pnpm/esbuild@0.18.11/node_modules/esbuild/lib/main.js:700:9)
at handleIncomingPacket (<REPO PATH>/node_modules/.pnpm/esbuild@0.18.11/node_modules/esbuild/lib/main.js:755:9)
at Socket.readFromStdout (<REPO PATH>/node_modules/.pnpm/esbuild@0.18.11/node_modules/esbuild/lib/main.js:676:7)
at Socket.emit (node:events:513:28)
at Socket.emit (node:domain:489:12)
ELIFECYCLE Command failed with exit code 1.
ERROR: command finished with error: command (<REPO PATH>/apps/resident) pnpm run build exited (1)
Hi folks, I'm going to close this issue for the time being. We're currently not actively working on new SvelteKit SDK features other than fixing bugs and adding general SDK improvements. As you can see, there are still some open points in the roadmap but we have to prioritize things and currently, other tasks have higher priorities.
Does this mean we won't do any of them? No! I'd love to get some stuff done once we have some time for it.
There's one exception to this, which is the (Vercel) Edge runtime support. We're working on getting there. However, to work on the necessary SvelteKit-specific part, we first have to refactor some general SDK internals first. This is being tracked in #8693.
Please feel free to open issues with specific bug reports or feature requests! thanks!
Discussed in https://github.com/getsentry/sentry-javascript/discussions/5838
Problem Statement
There is already support for the Svelte JavaScript framework, and now that SvelteKit is also in a 1.0 stable release we should extend the support.
See: https://svelte.dev/ SvelteKit: https://kit.svelte.dev/
If you are interested in this, please react to this issue and/or leave a comment below!
Solution Brainstorm
An SDK similar to what we have for NextJS, providing support for client- and server-side error and performance monitoring.
Initial Work
Initially, we'll focus on these tasks to release the first version of the SvelteKit SDK. While this version will still require manual instrumentation, it should be enough to release and receive early feedback from the community.
The following high-level tasks will be extracted to separate issues each (if applicable) to track them individually on a more fine-grained level:
Goal: Users can add and configure the SvelteKit SDK to their project and initialize the SDK for errors, performance and Replay. At this point, fully using the SDK will require manual wrapping of data fetchers and handlers. This SDK will work with the Node SvelteKit Adapter.
Advanced Features
Once we have a basic SDK, we start looking at more advanced features. These differ from stretch goal in the sense that they have immediate high value. For example: They make usage significantly easier or increase the supported platforms in which the SDK can be used.
Goal: Users no longer need to manually add Sentry wrappers to their data fetchers and handlers. Instead, this will be done automatically at build time. Additionally, users can use the SDK not just on Node servers but also on Vercel.
Stretch Goals
If we have enough resources and time, there are a couple of cool stretch goals to take a look at: We will likely not be able to implement all of these features from the start. That's okay. We can extract them to separate issues or implement them by demand at a later time.
Goal: The moon 🚀
Dog-fooding opportunities:
┆Issue is synchronized with this Jira Improvement by Unito