Reqest entity too large

[buremba]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
If the user flow involves some big HTTP requests and operations, the error logging fails with "Reqest entity too large" because Sentry tries to send full stack-trace and HTTP request logs to the backend server.

What is the expected behavior?
The SDK should truncate the body if it's too large.

Which versions of Raven.js, and which browser and OS are affected by this issue?
I'm using the version 3.6 with your SaaS offering.

[benvinegar]

because Sentry tries to send full stack-trace and HTTP request logs to the backend server.

Raven.js does not send HTTP request logs, unless you're doing something custom.

The SDK should truncate the body if it's too large.

It truncates frames. It doesn't send HTTP request bodies so it wouldn't know to do this.

Are you appending your own data manually or using a plugin like redux-raven-middleware? Please attach a copy of a sample outbound report and I can act on this.

I'm using the version 3.6 with your SaaS offering.

This version is pretty out of date now.

[buremba]

I use Angular plugin with default configurations but you're right, the version is pretty out of date. I upgraded to the last version and let you know if it occurs again. Thanks.

Here is a sample:
curl 'https://app.getsentry.com/api/app_id/store/?sentry_version=7&sentry_client=raven-js%2F3.9.2&sentry_key=KEY' -H 'Pragma: no-cache' -H 'Origin: https://app.rakam.io' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36' -H 'Content-Type: text/plain;charset=UTF-8' -H 'Accept: */*' -H 'Cache-Control: no-cache' -H 'Connection: keep-alive' -H 'DNT: 1' --data-binary $'{"project":"nope","logger":"javascript","platform":"javascript","request":{"headers":{"User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"},"url":"https://app.rakam.io/report-playground?query=select%201,2,3&options=%7B%22chartType%22:%22geo-cluster%22,%22limit%22:1000,%22enableStatistics%22:true,%22tableOptions%22:%7B%22enabled%22:true%7D,%22chartOptions%22:%7B%22latitude%22:0,%22longitude%22:1,%22title%22:2%7D,%22variables%22:%5B%5D,%22segments%22:%5B%5D,%22measures%22:%5B0,1,2%5D,%22dimensions%22:%5B%5D%7D&queryOptions=%7B%7D"},"exception":{"values":[{"type":"TypeError","value":"Failed to execute \'appendChild\' on \'Node\': parameter 1 is not of type \'Node\'.","stacktrace":{"frames":[{"filename":"https://app.rakam.io/static/components/raven-js/dist/raven.js","lineno":372,"colno":29,"function":"HTMLImageElement.wrapped","in_app":false},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":3,"colno":20753,"function":"HTMLImageElement.o [as _leaflet_click27]","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":2,"colno":17248,"function":"e._onMouseClick","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":1,"colno":5028,"function":"e.fireEvent","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":2,"colno":23910,"function":"e.togglePopup","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":2,"colno":23724,"function":"e.openPopup","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":2,"colno":23431,"function":"e.openPopup","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":1,"colno":21249,"function":"e.addLayer","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":1,"colno":29748,"function":"e._layerAdd","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":2,"colno":19069,"function":"e.onAdd","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":2,"colno":20008,"function":"e.update","in_app":true},{"filename":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","lineno":2,"colno":21514,"function":"e._updateContent","in_app":true}]}}]},"culprit":"https://app.rakam.io/static/dist/scripts/1.1-353348d0887eb92338a9.js","extra":{"cluster":"4c8e91d0-471e-4041-a11f-f818b2b757a1","name":"rakam-prod","type":"ui","session:duration":3993424},"breadcrumbs":{"values":[{"timestamp":1488365533.259,"category":"ui.click","message":"td > i.margin-horizontal-5.pointer.fa.fa-play-circle.green"},{"timestamp":1488365533.335,"type":"http","category":"xhr","data":{"method":"GET","url":"https://api.mixpanel.com/track/?data=%3D&ip=1&_=1488365533262","status_code":200}},{"timestamp":1488365533.497,"type":"http","category":"xhr","data":{"method":"POST","url":"https://webapp-1290649538.us-west- .......... TONS OF HTTP REQUESTS

[benvinegar]

TONS OF HTTP REQUESTS

So ... those look like breadcrumbs, and we limit those to 50 per page. If your URLs are explosively large, they could present a problem. So you could set maxBreadcrumbs: 20 or something.

[buremba]

They're quite large because these Mixpanel calls have a big base64 encoded query parameter that includes the event body. I believe that the best option here is to discard some third party analytics service calls such as Mixpanel or truncate the url if it's too large but it seems that both of them requires some work do be done in this repo, right?

[benvinegar]

Ah, that's very helpful. Yes, we should truncate this client-side.

[buremba]

It looks like I also removed Mixpanel HTTP calls in the snippet since they may include some user sensitive data but that part is particularly large.

[benvinegar]

Note, in the meantime you can use breadcrumbCallback to truncate (or disable) HTTP breadcrumbs. See config.

[derekrprice]

We are seeing this today with many large breadcrumbs, and it crashes the browser. I would argue that Sentry.io should NEVER crash the browser regardless of what the user does. Could you please add some sort of automatic client-side checking and truncation of the packet size before throwing an error in the client, like Sentry's Python integration did.

[derekrprice]

I think this issue needs to be reopened.

[kamilogorek]

What do you mean by "crash the browser"? Like... an actual crash? How did that happen? Can you provide some more details?

[derekrprice]

It threw an error in the browser, effectively crashing the JS application running there.

[derekrprice]

As for details on how to reproduce, log a lot of large breadcrumbs, then hit another error. Raven throws its own exception and does not log the original error, either to the console or to the server.

[derekrprice]

Ok, looking closer at this on my end, I may have been a bit alarmist. Sentry's thrown error is not crashing the application since it starts with our own JS error, but it IS true that the large number of breadcrumbs are preventing sentry from logging the error to the server. I think truncating the breadcrumbs in the client to ensure that the stack trace gets logged to the server should be standard. I would rather see the stack trace with a note about truncated breadcrumbs than nothing at all when my users are encountering real errors.