Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: Failed to execute 'send' on 'XMLHttpRequest' #126

Closed
nivos-saar opened this issue Dec 3, 2018 · 21 comments
Closed

Error: Failed to execute 'send' on 'XMLHttpRequest' #126

nivos-saar opened this issue Dec 3, 2018 · 21 comments

Comments

@nivos-saar
Copy link

Hey,
Once in a while we're receiving errors on requesting a gif.

  1. Why you're even requesting for that gif?
  2. This is the Error:
Error: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://events.launchdarkly.com/a/*.gif?*

Thanks

@eli-darkly
Copy link
Contributor

Hi. First, what version of the JavaScript SDK are you using? There is a bug that was fixed about 7 months ago that I think is responsible for this message; it shouldn't occur in any more recent version.

But to answer your question, that GIF URL is supposed to be a mechanism for transmitting analytics events back to LaunchDarkly if no other mechanism is available—that is, if the browser does not support cross-origin HTTP POST requests. In that case, assuming events are enabled, instead of using an XMLHttpRequest it is supposed to create an Image object that will load this URL asynchronously, and the query string in the URL contains encoded event data.

However, in older versions of the SDK, there was this bug where even when it was using an XMLHttpRequest, it would still use the image URL instead of the URL we normally post events to. This was fixed in version 2.0.0 as far as I know.

@eli-darkly
Copy link
Contributor

I forgot to add: even if you are using an older version of the SDK, I'm not sure why this HTTP request would be failing. While there was no good reason for it to be using the GIF URL, there's also no reason that should not have worked.

@nivos-saar
Copy link
Author

Thank you for your response. Sorry for not writing the version number in the issue.
We are using 1.7.4. I don't think that we'll upgrade anytime soon, as much as I understand there are some breaking changes which require us to make some changes on our side.

The request fails once in a while, do you have any workaround suggestion that we can implement while we're using an older version ??

@eli-darkly
Copy link
Contributor

Unfortunately, I don't have any idea what is causing the HTTP request to fail so I'm not sure what to suggest. I do know that when the browser gives you such a vague message ("Failed to execute 'send'") instead of a more specific HTTP error, it sometimes means that the code tried to do a cross-origin AJAX request and it failed due to CORS not being allowed. But the LaunchDarkly server specifically does allow CORS for that resource, so I don't know what is going on.

About the upgrade issue: was there a specific change you were concerned about? Although we did bump the major version to 2, that change wasn't really in keeping with semantic version standards— there were no backward incompatibilities, it's just that the implementation had changed quite a bit (basically in terms of how the SDK sends analytics events to LaunchDarkly). The only thing I can think of that could be considered a breaking change is that, in the functions that take an optional callback, they now return a Promise only if you don't pass a callback, whereas previously they always returned one; but that was more of a bug fix, since the previous behavior was undocumented and didn't really have a use case.

@nivos-saar
Copy link
Author

Thank you for you help friend!
I'll give the upgrade a try, I hope it will solve our problem 😎

eli-darkly added a commit that referenced this issue Dec 7, 2018
@suhasdeshpande
Copy link

suhasdeshpande commented Jan 14, 2019

Hi there,
I am also getting a similar error.
NetworkError · Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://events.launchdarkly.com/events/bulk/5b28465b9a879f37dfa0c746'

I'm on version "ldclient-js": "2.7.3",

Here is a gist of my implementation using SDK.

import { initialize, LDClient, LDUser } from "ldclient-js";
 const ldClient = initialize(this.ldConfig.sdkKey, user);
 ldClient.on("ready", () => {
   myStore$.dispatch({
        type: ClientActionType.LoadReleaseFlagsSuccess,
        releaseFlags: launchDarklyClient.allFlags(),
      });
 })

@eli-darkly
Copy link
Contributor

@suhasdeshpande - Well, the URL is correct in this case. If you're sure that there isn't an actual network connectivity issue that would prevent the browser from reaching that URL, then it's not clear what's going on. It could possibly be a problem with cross-origin requests not being allowed.

If you could raise a support issue here, the support department might be better able to investigate this than the SDK developers (though they will contact us if necessary for technical details).

I'm going to close this issue at present because there's not enough information to determine whether it's a problem with the SDK code itself.

@w0ofy
Copy link

w0ofy commented Apr 1, 2019

This comment might be off-base being that it may have nothing to do with this SDK, but since the exact issue I'm having is referenced here, per @suhasdeshpande 's comment, maybe an answer to this will help someone else strolling past this issue thread.

@suhasdeshpande Did you end up finding a solution to this error:
NetworkError · Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://events.launchdarkly.com/events/bulk/5b28465b9a879f37dfa0c746'

I am running into the exact same error and cannot trace anything that is useful in resolving this. I am not sure how to even reproduce.

@eli-darkly
Copy link
Contributor

For any problem report like this, it'd be helpful to know what browser and browser version you're using as well.

@w0ofy
Copy link

w0ofy commented Apr 4, 2019

I'm using Chome, Version 73.0.3683.86

Do you know if it's possible when passing a user object to initialize, if the user key value is undefined e.g. user: { key: undefined }...

The console error I'm getting (mentioned in my last comment) would be thrown? I just changed the code I have to pass an empty string if no "user key" is defined - maybe this will solve the issue? @eli-darkly

@eli-darkly
Copy link
Contributor

It's not valid to pass in a user without a key (either to initialize or to identify), but no, I don't see any way that that could account for the network error you're seeing.

In my experience, such an error always means either 1. an actual network error did occur (i.e. it couldn't reach the service at all, rather than the service returning an HTTP error status), or 2. the request was blocked by CORS restrictions. If it's the former, I have no way to diagnose it from here. The latter is possible, except I still haven't been able to figure out a reason why there would be a CORS problem—and also I would expect something like that to be a consistently occurring error, not an intermittent one (you said you're not sure how to reproduce it).

@redroot
Copy link

redroot commented Apr 15, 2019

Hi, I'm hoping to jump onto this discussion as well as we've had a spike in this error over the last two days despite not changing any code (we had 100s per day before but now we have 1000s)

  • Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://events.launchdarkly.com/events/bulk/5a5743205bdd0d2171352659': Synchronous XHR in page dismissal
  • mainly in Chrome 73.0 on Windows 10 and Chrome Mobile.
  • Running ldclient-js 2.9.5 since April 1st.

The client code is present on all our pages and we make one call after initialising the client on the frontend:val = client.variation(key, null);. According the README this is a synchronous request, and the only way I can actually recreate this is by trying to refresh the page before the request has completed, which then throws the above error in the console before reloading the page. If everything loads, and then I navigate away, no error is thrown.

This makes me think this isn't actually affecting any users who actually stay on the page, only those who bounce before the variation call has completed. Makes me wonder if this a Chrome specific issue? Some sort of deterrent from the dev team to stop using synchronous XHR? There is a related commit in Chromium from 3 months ago https://chromium.googlesource.com/chromium/src/third_party/+/ae9a7d1e4158dc3816c59a27c67fb59777fcba78

@eli-darkly
Copy link
Contributor

@redroot - Thanks for looking into this. There are a few different types of request involved here, so I don't think what you're seeing is necessarily related to what the other users were seeing, but it's relevant.

First, calling variation doesn't do any I/O at all; the method is synchronous in that it returns a value right away without deferring any actions, not because it performs a synchronous HTTP request (or any request).

Requests to events.launchdarkly.com are for posting analytics events (such as the ones generated by variation). That normally happens in an asynchronous flush task that is triggered by setTimeout, and the request itself is also async.

What you're seeing is a special case. There is a beforeunload handler that is called whenever the current page is about to go away. It checks if there are any events waiting to be sent (i.e. if the flush task has not yet fired), and if so, it attempts to send them using a synchronous HTTP request (if it were async, it would have no chance to complete before the page got unloaded). All versions of ldclient-js have this. The intention is to minimize any loss of analytics events, so that your dashboard is as up to date as possible, without requiring you to use a very short event flush interval.

We suspected that browsers might stop supporting this kind of thing at some point, but we hadn't seen this specific change in Chrome, so thanks for that. We'll have to think about the best way to adapt. As for why you were seeing it a little before, but now are seeing it a lot, I would guess that either more of your users have the latest Chromium now, or for whatever reason your application is generating events more often than it used to so it's more likely to have some unsent ones in the queue at page unload time.

The reason I doubt that the other comments had the same cause is that they didn't include the "Synchronous XHR in page dismissal" message; I'm assuming they didn't just forget to copy that, since it's pretty distinctive.

@nivos-saar
Copy link
Author

@eli-darkly that's correct, in the beginning, it wasn't the problem and we did upgrade to the latest LD version.
But @redroot is right, since Chrome 73, Chrome no longer allows synchronous XHR requests to be executed during page dismissal you can see it here

That means we're receiving lots of errors from our users and also it blocks our deployment process since the automated tests are failing with the error @redroot mentioned above.

Any suggested workaround?
Thanks!

@ajhartenbaum
Copy link

Can we please reopen this @eli-darkly ? Or I can make a new issue. A lot of people are having this problem due to the Chrome update

@eli-darkly
Copy link
Contributor

@ajhartenbaum Absolutely: #147

@redroot
Copy link

redroot commented Apr 17, 2019

thanks @eli-darkly

@suhasdeshpande
Copy link

@eli-darkly I ended up pausing sendEvents: false as this was throwing xss errors (I think although I am not entirely sure at this point since its a distant memory. I did not face any other errors integrating the SDK. Works pretty nicely. I don't have immediate needs for events at present but I will try out and see if I still face any issues with this. Thanks.

@rblalock
Copy link

My popup blocker in firefox caused the error above btw. I disabled it for my site and I dont get the error anymore.

@eli-darkly
Copy link
Contributor

@rblalock That's unexpected, and we'd appreciate if you could provide more details, either here or in a support request.

@rblalock
Copy link

Sure. I'll create a separate ticket

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants