feat(cloudflare): Add option to opt out of capturing errors in wrapRequestHandler

[Lms24]

This PR adds a captureErrors option to the wrapRequestHandler options from @sentry/cloudflare. While by default, the wrapper should capture exceptions (for example, when it's used in pure CF worker functions), it shouldn't do that when it's used in higher-level SDKs, like SvelteKit. There, we want our other error capturing implementations to do the job.

This came up because as reported in #16847, our CF wrapper caught thrown redirect(...) objects which we deliberately ignore in our SvelteKit SDK (they're a control flow mechanism in Kit and not an actual error).

In a follow-up PR, I'll set this option in the SvelteKit SDK to false.

If reviewers prefer, I can change the option to be a callback where we'd pass in the error and decide on capturing based on a returned boolean. I initially decided against it because it adds more complexity than necessary but happy to change.

[andreiborza]

Code LGTM, I was just wondering if higher-level SDKs can then capture these errors within the right scope, or if there could be any issue around that 😅.

[Lms24]

just wondering if higher-level SDKs can then capture these errors within the right scope, or if there could be any issue around that

Very good question because it made me double-check the implementation, thanks! Fortunately, in the SvelteKit case, the scope data is still kept because the order of scope forking is correct and we capture errors in an inner scope of the CF wrapper:

// hooks.server.ts
export const handle = sequence(
	initCloudflareSentryHandle({
		dsn: '...',
	}), // <-- inits SDK, creates isolation scope, sets CF data, but no longer captures error
	sentryHandle(), // <-- sets SvelteKit data AND captures error (correctly)
	redirectToSentryPage // <-- user-created middleware(s) that could throw
	// other SvelteKit lifecycle APIs like `load` functions that could throw are executed now
        // finally, we exit sentryHandle() and then initCloudflareSentryHandle() middlewares
);

@s1gr1d, since your working on Nuxt on CF: Do you use wrapRequestHandler and would this change still guarantee errors being captured correctly?

[s1gr1d]

Should be fine in Nuxt as the handler has its own isolation scope

sentry-javascript/packages/nuxt/src/runtime/plugins/sentry-cloudflare.server.ts

Lines 119 to 138 in b746c23

	return wrapRequestHandler(requestHandlerOptions, () => {
	const isolationScope = getIsolationScope();
	const newIsolationScope =
	isolationScope === getDefaultIsolationScope() ? isolationScope.clone() : isolationScope;
	const traceData = getTraceData();
	if (traceData && Object.keys(traceData).length > 0) {
	// Storing trace data in the WeakMap using event.context.cf as key for later use in HTML meta-tags
	traceDataMap.set(event.context.cf, traceData);
	logger.log('Stored trace data for later use in HTML meta-tags: ', traceData);
	}
	logger.log(
	`Patched Cloudflare handler (\`nitroApp.localFetch\`). ${
	isolationScope === newIsolationScope ? 'Using existing' : 'Created new'
	} isolation scope.`,
	);
	return handlerTarget.apply(handlerThisArg, handlerArgs);
	});