fetch instrumentation breaks is-network-error package in Safari

[camsteffen]

I am trying to use the is-network-error package to filter out network errors being sent to Sentry, but Sentry fills in error.stack which breaks is-network-error's expectation that error.stack === undefined in Safari. See sindresorhus/is-network-error#7.

I'm not sure what a proper solution to this problem should look like. Perhaps Sentry could add some flag to the error object to indicate that it is was modified?

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[chargome]

hey @camsteffen thanks for writing in!

Since this is rather a niche case I'm not sure if we will update the SDK for it but maybe a workaround like this works for you (assuming is-network-error does not care about the stack except in the safari case):

beforeSend: (event, hint) => {
    const { name, message } = hint.originalException;
    const errorWithoutStack = new Error();
    errorWithoutStack.name = name;
    errorWithoutStack.message = message;
    errorWithoutStack.stack = undefined;
    if (isNetworkError(errorWithoutStack)) {
      return null;
    }
    return event;
  }

[camsteffen]

I am open to having some workaround, but I also sympathize with is-network-error's stance that Safari's error message "Load failed" is too generic to assume it is a network error.

Also I feel that this use case is not terribly niche. Network errors are kind of inevitable noise, the Sentry docs specifically suggests possibly filtering out network errors, filtering network errors is a non-obvious problem since they are platform specific, so the is-network-error package is a logical solution.

I placed a bid in the is-network-error issue that it could check error.name instead of error.stack. If that idea is not accepted, then I think I will just do that in a workaround. So I'm good to close this issue. Thanks for your consideration!

[sindresorhus]

If something works when Sentry is not enabled and stops working when Sentry is enabled, it is a problem with Sentry. At minimum it should be possible to detect that Sentry has modified the error, maybe with a non-enumerable property on the error.

[chargome]

@sindresorhus we do add a non-enumerable __sentry_captured__ to the error once we capture it.

[LinusU]

Ran into this as well today. It's a bit unfortunate that adding Sentry to our projects makes other packages stop working 😅

With that said, I can see why this is a bit of an edge case...