Sentry requests are pending indefinitely

[antoantonydh]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Self-hosted/on-premise

Which package are you using?

@sentry/browser

SDK Version

7.16.0

Framework Version

Angular 14.2.6

Link to Sentry event

No response

Steps to Reproduce

Sentry requests are pending indefinitely. It is not happening to all the requests. But to the few of them randomly. I checked if it is related to the payload issue by copying the requests from the chrome network tab to postman, and it is working fine without any issues. So, it is happening only from the browser.

I tried to revert to the older version of sentry lib v7.12.1 and seems like issue is solved. Is it related to this change #5697?

Expected Result

Sentry requests should either send to server or gives some error instead of pending state

Actual Result

[lobsterkatie]

Hi, @antoantonydh.

Thanks for writing in! The change you linked does sound like a plausible cause. @Lms24, when you get a chance, would you mind giving this a look?

[antoantonydh]

Thanks @lobsterkatie. We noticed that, requests are in pending state usually have a large payload (38kB - 40kB). But if the size is the problem, it should not work when we sent the same request from the Postman right?

[Lms24]

Hi @antoantonydh.

This sounds strange to me and I can't recall that this came up before. I have a couple of questions:

• You wrote that you're using @sentry/browser with Angular. Have you tried using @sentry/angular for first-class support with Angular? However, I'm quite certain that this won't change a lot in terms of this problem. Nevertheless, maybe it's worth a try?
• Reading a little bit about the keepalive flag from fetch (which we use to not cancel our outgoing requests on navigations, as explained in feat(browser): Use fetch keepalive flag #5697), it seems to me as if it should work well in chromium-based browsers. There are problems in Firefox so I'm curious if you noticed any differences between browsers?
• Are you using any libraries that modify fetch (e.g. monkey patch or instrument it in any way) other than the Sentry SDK?
• Are you using Angular's HttpClient or any third-party Http request libraries?
• Does this happen in special situations? E.g. when you navigate to a different page/route? Or does it also happen to requests when you don't navigate at all?
• Have you noticed if it affects certain types of payloads? E.g. errors vs. transactions?

Let's see if we can narrow this down a little. I'm also curious if this only affects Angular users or if it happens in other frameworks as well (if readers of this issue are affected by the problem please feel free to comment. A last idea would be that this has to do something with Angular's HttpClient (assuming this behaviour only happens in Angular projects). However, I think it's unlikely, as our SDK doesn't interact with it at all.

[Lms24]

Reading this post (which I admit has little in common with your problem other than the pending state), can you verify if the requests that are pending actually made it to Sentry? I.e. do the events show up in Sentry (as issues or transactions)?

[antoantonydh]

@Lms24 Thanks for the reply and looking into this.

You wrote that you're using @sentry/browser with Angular. Have you tried using @sentry/angular for first-class support with Angular? However, I'm quite certain that this won't change a lot in terms of this problem. Nevertheless, maybe it's worth a try?

I think, our project started using this initially and never changed the package to @sentry/angular. We have some logic, which we are trying to combine/merge the logs, after only we will call the sentry functions.

Reading a little bit about the keepalive flag from fetch (which we use to not cancel our outgoing requests on navigations, as explained in #5697), it seems to me as if it should work well in chromium-based browsers. There are problems in Firefox so I'm curious if you noticed any differences between browsers?

I tried in Firefox and there are no issues like this. I used the same env and same user for testing. But in chrome, we are getting pending requests and in the Firefox all are done.

Are you using any libraries that modify fetch (e.g. monkey patch or instrument it in any way) other than the Sentry SDK?

No, we are not using anything else. One thing, I noticed for the fetch API. Those are getting the angular polyfills by default.

Are you using Angular's HttpClient or any third-party Http request libraries?

Yes. only the HttpClient from Angular

Does this happen in special situations? E.g. when you navigate to a different page/route? Or does it also happen to requests when you don't navigate at all?

Not at all. It is happening in both scenarios.

Have you noticed if it affects certain types of payloads? E.g. errors vs. transactions?

I think it is mostly happening to events

{"type":"event"} {"message": "--------------------"}

[antoantonydh]

Reading this post (which I admit has little in common with your problem other than the pending state), can you verify if the requests that are pending actually made it to Sentry? I.e. do the events show up in Sentry (as issues or transactions)?

We just checked it, and it never reached to the sentry. Somehow it is still stuck at the chrome

[jazlalli]

if readers of this issue are affected by the problem please feel free to comment.

I'm not sure if this is strictly the same issue, but it seems too similar to be coincidental, so sharing my experience in case it helps.

I'm using the @sentry/react package v6.11.0. Some requests were getting through fine, e.g. an error in a React lifecycle method makes it to Sentry. But if I threw an error within an event handler (a regular async / await function), it remained pending and never made it to Sentry. This occurred in Chrome and Firefox, though each browser showed me different info.

Chrome

Firefox

but interestingly, a response (of sorts)

---

Following the crumb that Firefox revealed (Payload Too Large), I inspected the payload of the pending request, and it contained a lot more than I was expecting. I'm running in dev mode, so there are lots of logs in the browser console, all of which were part of the payload that was attempting to be sent (I was surprised by this). I suppressed the console logs, and then the error was successfully sent to Sentry.

@antoantonydh might be worth exploring this route further in case it's the cause? Appreciate it might be unlikely given that you said the equivalent request via Postman worked for you, whereas the equivalent cURL request for me returned the same response (413 Payload Too Large).

[antoantonydh]

@jazlalli Thanks for sharing the details. In my case, it is totally random, and even the payload is only less than 40kB. As mentioned, when I downgrade to the v7.12.1 it is not happening anymore. But I am yet to test it fully. I will confirm with in couple of days

[antoantonydh]

@Lms24 we have deployed the downgraded version v7.12.1, and now we have logs coming in properly. So, I suspect either the issue was because of that keepAlive feature or some other recent changes happened.