Bug: no xhr breadcrumbs for error in onreadystatechange

[ilfa]

I think it's a bug

When Raven instruments XMLHttpRequest and error occurs in onreadystatechange user function we don't see current request details in breadcrumbs for current error, because Raven log request in onreadystatechange after user code.

What is the current behavior?

Here is fiddle, just check console and see order of ravenTransport breadcrumb and setBreadcrumbCallback messages.

What is the expected behavior?

It will be great if Raven can put xhr request info in breadcrumbs for onreadystatechange too.

[kamilogorek]

@ilfa sorry for such a long response time, we were swamped. I'm not sure if I understand the issue tbh. Do you by any chance still have this fiddle link? 😅

[kamilogorek]

Closed due to inactivity. Please feel free to reopen this issue if this also happens in v4 sdk. Cheers! :)

[stefan-hc]

Hello,

I think I've encountered the same problem (we can discuss if this is a problem or a bug) in current version of Sentry. I'm not sure if I should open new issue for it, or if we can reopen this one. Please guide me. /cc @kamilogorek

The problem:
When using Sentry together with https://github.com/axios/axios (it's a frontend library wrapping XMLHttpRequest with a simpler API) one can write a following webapp code: (more-less)

async function getUser() {
  try {
    const response = await axios.get('/user?ID=12345');
    ...
  } catch (error) {
    ...
    Sentry.captureException(error);
  }
}

This reports the request/response error to Sentry. So far so good. However, out-of-the-box, one important data is missing in such scenario: the report will not contain the xhr breadcrumb for the /user?ID=12345 call.

It is because both webapp handler (catch (error)) and Sentry instrumentation are attached to the same event: onreadystatechange. However, Sentry instrumentation is attached as the second handler, so the breadcrumb for this particular XHR is registered only after capturing exception to Sentry. Immediately after, but after anyway.

To better illustrate the issue, I think the following variant would capture the breadcrumb in the report perfectly:

async function getUser() {
  try {
    const response = await axios.get('/user?ID=12345');
    ...
  } catch (error) {
    ....
    setTimeout(() => Sentry.captureException(error), 0); //to allow other onreadystatechange listeners to execute
  }
}

Is this expected behavior intended by Sentry design? Or is there a flaw in Sentry xhr breadcrumb instrumentation affecting this particular scenario?

As a reference, the relevant code from axios: https://github.com/axios/axios/blob/master/lib/adapters/xhr.js#L28

var request = new XMLHttpRequest();
(...)
request.open(config.method.toUpperCase(), buildURL(fullPath, config.params, config.paramsSerializer), true); 
// above will trigger Sentry instrumentation handler: https://github.com/getsentry/sentry-javascript/blob/master/packages/utils/src/instrument.ts#L221-L232
(...)
request.onreadystatechange = function handleLoad() {
//above will add onreadystatechange handler (as first handler, prior to Sentry's one)
(...)
request.send(requestData);
// above will trigger Sentry instrumentation handler: https://github.com/getsentry/sentry-javascript/blob/master/packages/utils/src/instrument.ts#L238-L267
// which attaches Sentry's onreadystatechange handler, but it's too late - it will be already second

[kamilogorek]

@stefan-hc hey, I just tried to reproduce this exact use-case with no luck. Are you able to do that for me, please?

Here is my test case example and the results (which includes both, error and breadcrumb itself):

[kamilogorek]

@stefan-hc and more "real-world" endpoint:

[stefan-hc]

Sure, will do. Give me a moment :)

[stefan-hc]

One thing that I've noticed: you're trying to reproduce this with Node.js environment, am I correct? I've encountered this problem when using Sentry in browser. So I speculate this might be browser-specific thing? Maybe node.js has different implementation of "onreadystatechange" handlers...

In anyway, I'll try to prepare you later this day a fiddle illustrating my issue. Ok?

[kamilogorek]

Ah, you are correct. I somehow linked Axios with node environment in my head by default. Reproduced it locally. Will try to debug this week.

[stefan-hc]

Jolly good.

Just for the record: it's not very urgent/important to me, as I went with setTimeout(() => Sentry.captureException trick and it seems to work good enough™. I can live with that for a longer while. Still, I find this solution to be hack'ish - it would be cool to get rid of it at some point in the future.

Thanks for addressing my report.