Tunnel only as a fallback on network errors

[mbrevda]

Problem Statement

It would be great if tunnel was used as a fallback in the case of a detected network error and not the default. This would conserve lots of bandwidth on high-volume sites by not sending all requesters unnecessarily.

Solution Brainstorm

It might be possible to parse the dsn and place a test call to the sentry API to test but it seems like something that could be easily incorporated in the SDK and should be a development concern.

[lforst]

Hi, thanks for the idea! I like it.

Thoughts:

• I hope network errors caused by ad-blockers are detectable somehow.
• We could add an option that is called something like tunnelOnNetworkError or similar.
• Right now this could actually be implemented via a custom transport with not too much effort.

I don't think this is a priority for us at the moment so I'll backlog it. We may get to it one day or somebody contributes a good solution.

[mbrevda]

Don't think adblockers are detectable per se, happy to always fall back on any network error. Can you share a link or example for a custom transport?

[lforst]

@mbrevda You can take our fetch transport as an example:

sentry-javascript/packages/browser/src/transports/fetch.ts

Lines 12 to 15 in b781d51

	export function makeFetchTransport(
	options: BrowserTransportOptions,
	nativeFetch: FetchImpl = getNativeFetchImplementation(),
	): Transport {

[mbrevda]

It seems there is different internal handling when a tunnel is used (for example, when creating the envelope). Is a custom transport all that's needed here?

[lforst]

You're right, the tunnel option will put the client key inside the payload as opposed to the query param. I guess you could forward the client key with a mechanism like headers and the tunnel server adds it back as a query param.

[mbrevda]

seems like lots of work for userland - seems like it be much simpler to just allow fallback to tunnel on network error (or based on a predicted function)

[lforst]

seems like lots of work for userland - seems like it be much simpler to just allow fallback to tunnel on network error (or based on a predicted function)

I agree. It's the usual factors that are the reason why it is not implemented like this already: Complexity, Bundle Size, Development & Maintenance Efforts.

[AbhiPrasad]

We'll be doing this as part of #14248 - closing this issue so we can track it there instead.