How to properly avoid catching some HTTP error codes on my API calls?

[igorsantos07]

I've just implemented an API response that answers with a 304 Not Modified and, no matter what I do, I still get interrupted by Sentry raising the error, even when I'm purposely ignoring the exception from Axios.

The only way I found to keep development going is to completely comment out the Sentry.init() call.

More specifically, here's what I tried that didn't work:

• commenting out entirely the inclusion of HttpClient
• adding specific status codes to the instantiation of HttpClient
• add 304 to the list of ignoreErrors
• pray

Here's the sanitized, full version of the call we make:

import { HttpClient } from '@sentry/integrations'
import * as Sentry from '@sentry/react'
import { BrowserTracing } from '@sentry/tracing'
import history from 'router/history'
import { store } from 'state/_store'
import { getAccount } from 'state/Account'
import { currentVersion, Locale, platform } from 'utils'

//no need to capture any development error and send to Sentry ¯\_(ツ)_/¯
const IS_PROD = platform.isProd()

//TODO use an ErrorBoundary so at least we can continue after the error... hopefully? https://docs.sentry.io/platforms/javascript/guides/react/features/error-boundary/
Sentry.init({
	dsn: 'https://yo@nope.ingest.sentry.io/nah',

	//https://docs.sentry.io/platforms/javascript/guides/react/configuration/releases/
	release    : `myapp-react@${currentVersion()}`,
	environment: platform.env(),

	replaysSessionSampleRate: IS_PROD? 0.1 : 0, //so we can sniff on how users tend to use the app :))
	replaysOnErrorSampleRate: IS_PROD? 1.0 : 0, //so we can see how the heck they managed to break our pretty app :((

	//if tree-shaking is desired for integrations: https://docs.sentry.io/platforms/javascript/guides/react/configuration/tree-shaking/#tree-shaking-default-integrations
	integrations: [
		new BrowserTracing({
			routingInstrumentation: Sentry.reactRouterV5Instrumentation(history),
		}),

		//this is NOT necessary to include console messages in error reports - it creates a new issue/entry/message for every single thing logged to the console!
		// new CaptureConsole(),

		//captures errored HTTP requests; cannot capture headers/cookies with sendDefaultPii=false
		new HttpClient({
			failedRequestStatusCodes: [402, [404, 499], [500, 599]],
			// failedRequestTargets: [/\/manager\/api\//]
		}),

		new Sentry.Replay(),

		//might be useful if we need to append data to errors
		//https://docs.sentry.io/platforms/javascript/guides/react/configuration/integrations/plugin/#extraerrordata
		// new ExtraErrorData(),

		//Changes the file paths send to Sentry
		//https://docs.sentry.io/platforms/javascript/guides/react/configuration/integrations/plugin/#rewriteframes
		// new RewriteFrames({
		// 	root: '',
		// 	prefix: '',
		// })
	],

	//set to true to capture personally identifiable information; BEWARE OF THE GDPR RISKS!!
	//with this set to false, the HttpClient cannot capture headers and cookies
	sendDefaultPii: false,

	//the default is 3, but then we move up to 10, so we can properly read the Redux state tree
	normalizeDepth: 10,

	//https://docs.sentry.io/platforms/javascript/configuration/options/#initial-scope
	initialScope: {
		tags: { /* here be some extra tags */ },
		user: {
			ip_address: '{{auto}}',
			//other user details are set at App.js, since we need to check if they're already logged in
		}
	},

	//More "weird" errors might be filtered out by using this whole list https://docs.sentry.io/platforms/javascript/guides/react/configuration/filtering/#decluttering-sentry
	ignoreErrors: [
		'unstable',
	],
	denyUrls    : [
		// Chrome extensions
		/extensions\//i,
		/^chrome:\/\//i,
	],

	//https://docs.sentry.io/platforms/javascript/guides/react/configuration/sampling/
	sampleRate: 1, //100% of errors will be sent to Sentry
})

[AbhiPrasad]

@igorsantos07 this is because we monkeypatch xhr which causes us to be part of the frames, this is not related to the httpClient integration, but is instead controlled by: https://docs.sentry.io/platforms/javascript/configuration/integrations/trycatch/ (which wraps XMLHttpRequest)

sentry-javascript/packages/browser/src/integrations/browserapierrors.ts

Lines 80 to 82 in 58a36e4

	if (_options.XMLHttpRequest && 'XMLHttpRequest' in WINDOW) {
	fill(XMLHttpRequest.prototype, 'send', _wrapXHR);
	}

[igorsantos07]

So I guess the docs you linked are outdated, since they don't mention XMLHttpRequest... Should I open an issue?

It's kinda confusing, since it is an HTTP error with an error code, so I guess you can understand my confusion with httpClient?
And then, what should I do in this scenario to skip surfacing some of the HTTP errors my application gets?

[AbhiPrasad]

I agree it's confusing and that we should improve the docs here - PRs are welcome! https://github.com/getsentry/sentry-docs

And then, what should I do in this scenario to skip surfacing some of the HTTP errors my application gets?

So the browerApiErrors integration reports an error if user code threw an error while executing xhr.onload, xhr.onerror, xhr.onerror, or xhr.onreadystatechange - not if a response returning 5xx. A 5xx response is only captured by httpClient integration. By default httpClient only capture errors around 5xx, not 4xx or 3xx responses.

My theory here is the problematic behaviour is with axios throwing an error within xhr.X (not sure which one), which is why sentry is reporting it. Sentry rethrows the error, which makes it show up in the console:

sentry-javascript/packages/browser/src/helpers.ts

Line 120 in 58a36e4

throw ex;

Because sentry rethrows, even if axios swallows the exception itself the error is still being thrown and it bubbles up 😢.

Just a theory though, would know more if I can reproduce it on my end.

This is not ideal, but I think to get around this the best thing to do is to filter the integration in dev mode: https://docs.sentry.io/platforms/javascript/configuration/integrations/#removing-a-default-integration - the integration name is TryCatch.