Bugsnag-js: Payload size is limited to the browser URL length limit?

Created on 16 Jun 2017  ·  17Comments  ·  Source: bugsnag/bugsnag-js

While working on the client side Bugsnag integration for one of our internal apps, I noticed that error notifications failed to be sent when I included the application state as metadata.

For context, our application stores the UI state in a single object using Redux; serialized to JSON it's about 160 kilobytes. That is quite a lot of data, but gzip reduces it to under 30 kilobytes and we could most likely remove a lot of extraneous data to make it even smaller.

However, since this library sends everything encoded as a query string (#217), it seems that the maximum length for an error notification is under 2000 characters, which isn't enough for anything non-trivial.

It's very likely we have missed dozens if not hundreds of error reports because the stack trace or metadata has been too large. :/

We are going to write a minimalistic JSON-based replacement for this library. In the mean time, it would nice if the readme or the documentation mentioned this fairly low request size limit.

Most helpful comment

Hi @marbemac, we are working on a full rewrite of the JS notifier which is nearing completion. It uses a cross-domain POST so this problem completely goes away.

It should be ready for early/beta testing in the next few weeks. If you're up for trying it (as for anybody on this thread) let me know! Otherwise it won't be much longer than that (provided there are no major issues to resolve) that it will be fully released.

Thanks for your patience!

All 17 comments

I hit the same problem, and it's simply a show stopper for us.

Setting the handler to xhr should do the trick.

Bugsnag.notifyHandler = "xhr" ;

https://docs.bugsnag.com/platforms/browsers/configuration-options/

P.S. It does not solve issue

Hey folks, sorry to have left you hanging for so long on this one!

As @ankurk91 suggests, setting the notifyHandler to "xhr" will use a HTTP POST delivery mechanism which allows much larger payloads.

The default "GET" method is to support some old IE browsers (the specifics of which escape me at this moment in time), so just be aware that there may be some impact there depending on the browser usage of your users.

Looking at the source, it still seems to be using GET:

if (notifyHandler === "xhr") {
  var xhr = new XMLHttpRequest();
  xhr.open("GET", url, true);
  xhr.send();
}

I'm still getting HTTP 413.

CORS does not seem to be quite right on this resource either:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://acme.com:2990' is therefore not allowed access. The response had HTTP status code 413.

I agree with @konrad-garus. "xhr" doesn't fix anything. It still uses ´GET` and sends the payload as an URL - it suffers from exactly the same issues as the legacy method.

Argh, sorry I definitely jumped the gun with recommending that solution as you are both correct, it doesn't help with your problem 😞 .

For a bit of context, I've just started here at Bugsnag to look after the JS platforms. This means the JS notifiers (this repo, and the node one) will be receiving more attention from now on. Please excuse me while I hit the ground running and get up to speed on the current state of things.

In terms of a solution that will help you right now I can't offer any suggestion other than not including large data structures in metaData, but have you found the breadcrumbs feature to be useful at all? Could you add a piece of Redux middleware that drops a breadcrumb on each Redux state mutation with the action/data? I know it won't get you the entire state data structure at the time of the error, but you would see the state mutations that led to the reported error.

Longer term, we are looking at revamping this notifier entirely, and will be offering more robust delivery mechanisms. The specifics of which are still to be fleshed out, but the feedback provided here is definitely shaping requirements and the future of the project, so thank you for taking the time write up the issues you've been facing 🙏.

P.S. I've added an internal ticket to get this added 👇

In the mean time, it would nice if the readme or the documentation mentioned this fairly low request size limit.

I've added a note to the documentation, as you requested @paavohuhtala:

https://docs.bugsnag.com/platforms/browsers/faq/#why-is-my-payload-not-being-sent-being-rejected-with-status-code-413

The worst thing here that 413 error may appear even when metadata parameter is empty. Stacktrace could also easily exceed the limit when script path is a long string and stacktrace is moderately deep.

I think that the library should allow skipping stacktrace for handled exceptions.

@bengourley any news on this one? Really enjoy Bugsnag, but we're about to look for another solution because we can't realistically use this if errors randomly don't get sent (for example, when stack trace is anything but very short). We have removed the metadata, but stack traces push the request over the character limit.

Hi @marbemac, we are working on a full rewrite of the JS notifier which is nearing completion. It uses a cross-domain POST so this problem completely goes away.

It should be ready for early/beta testing in the next few weeks. If you're up for trying it (as for anybody on this thread) let me know! Otherwise it won't be much longer than that (provided there are no major issues to resolve) that it will be fully released.

Thanks for your patience!

Exactly what we were hoping for, looking forward to it!

@bengourley let us know when its ready and we'll try it out on our staging environment.

Hey @marbemac (and anybody else on this thread who's interested), you can now try out the v4 beta!

Intro/instructions are here: https://docs.google.com/document/d/1HBBLyVv9FHsNmbkRLx58WbtisMRVHwDoR3pnxac9JQQ/

Please let us know how you get on.

🚢 v4 is now published. Please upgrade!

See UPGRADING.md and full docs for more info 😄

I assume that means the new max payload size is 1 MB, since that's the default for ngnix, which I think you're using.

We're not using nginx, but yeah it's 1MB

Thanks!

On Tue, Dec 18, 2018, 5:13 PM Ben Gourley <[email protected] wrote:

We're not using nginx, but yeah it's 1MB


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bugsnag/bugsnag-js/issues/245#issuecomment-448390932,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ArpyN3nIA9OBNdqZBJFhBeby2NO8E7aOks5u6WiGgaJpZM4N8POO
.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lifeiscontent picture lifeiscontent  ·  6Comments

H2go picture H2go  ·  5Comments

killia15 picture killia15  ·  6Comments

foxyblocks picture foxyblocks  ·  5Comments

darkyndy picture darkyndy  ·  4Comments