AbhiPrasad
commented
3 months ago Initial thinking of the general API.
We're probably only going to support ES modules syntax.
Current toucan requires you to always instantiate new Toucan. Ideally we can avoid this by exposing a helper that wraps export default obj from the entry point.
It would probably automatically try to read env.SENTRY_DSN to get the sentry dsn.
export default withSentry({ beforeSend }, {
async fetch(request, env, ctx) {
return new Response('Hello World!');
},
});For further customization, you can take a function withSentryHandler that isolates sentry to the specific handler you care about. This allows you to override how sentry is initialized for that specific handler without
export default withSentry({ tracesSampleRate: 1.0 }, {
async fetch: withSentryFetchHandler((init) => (request, env, ctx) => {
const client = init({ tracesSampleRate: 0.5, request, env, ctx });
// do whatever you want with client
return new Response('Hello World!');
}),
});With the withSentry API's you'll need to have compatibility_flags = [ "nodejs_als" ] on in your wrangler.toml, otherwise you risk request bleeding (we require AsyncLocalStorage to do isolation).
If you don't want any node_compat, we can't do the global withSentry magic function, so you'll need to manually create a client.
import * as Sentry from '@sentry/cloudflare-workers';
export default {
async fetch(request, env, ctx) {
const client = new Sentry.CloudflareWorkersClient();
const scope = new Sentry.Scope();
scope.setClient(client);
try {
handler();
return new Response('Hello!');
} catch (e) {
scope.captureException(e);
return new Response('Something went wrong! Team has been notified.', {
status: 500,
});
}
},
};Unfortunately performance is not active here because the parent child relationship is wrong, so maybe we gate performance behind requiring compatibility_flags = [ "nodejs_als" ]. The same also applies for automatic instrumentation adding breadcrumbs, we risk attaching to the wrong request. All automatic instrumentation (like automatically instrumenting d1 or r2 bindings) might be turned off if we cannot access asynclocalstorage.
We also need to add support for Version metadata binding - I'm imagining this is easiest to expose as an init config where you tell us what environmental variable to access for this info, and we automatically update releases and such.
ChristianJacobsen
F0rce
timfish
seo-rii
Lms24
BYK
zephraph
saturnonearth
KyGuy2002
andreiborza
ref https://github.com/getsentry/sentry-javascript/issues/2484 ref https://github.com/getsentry/sentry-javascript/issues/5611
Let's add some 1st class cloudflare workers support (finally)!
We've had https://github.com/robertcepa/toucan-js for a while that has worked great, but doesn't match our unified API and doesn't have full support for performance, cron monitoring, and more.
First we can start off by making a basic package,
@sentry/cloudflare-workersOnce the SDK is in a good state we can think about better instrumentation for the different bindings that cloudflare workers exposes. Top of mind is:
At the same time we should make sure that we add support for our metaframeworks to use the Cloudflare workers SDK