Reqest entity too large #874
Comments
Raven.js does not send HTTP request logs, unless you're doing something custom.
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.
This version is pretty out of date now. |
|
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: |
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 |
|
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? |
|
Ah, that's very helpful. Yes, we should truncate this client-side. |
|
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. |
|
Note, in the meantime you can use |
|
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. |
|
I think this issue needs to be reopened. |
|
What do you mean by "crash the browser"? Like... an actual crash? How did that happen? Can you provide some more details? |
|
It threw an error in the browser, effectively crashing the JS application running there. |
|
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. |
|
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. |
|
We'll rethink the approach to this issue in the next major release. Right now, however, it'd be too much overhead to do this operating for every single event and it may impact the performance of our SDK. We do provide all the required tools so that developers can do that themselves if they are willing to - https://github.com/getsentry/raven-js/blob/deff2f06b40d10389705167c25efc2e737240e3e/packages/raven-js/src/utils.js#L486-L553 If you want to calculate the size of the breadcrumbs every single time and truncate them if they are too heavy, feel free to do that. Here's how you'd approach something like this: const utils = require('../node_modules/raven-js/src/utils'); // or just extract it to your own file, its up to you
const MAX_SIZE = 50 * 1024;
function truncateBreadcrumbs (data) {
// Handle edge-case to prevent an infinite loop
if (utils.jsonSize(utils.stringify(data)) > MAX_SIZE) {
data.breadcrumbs = data.breadcrumbs.split(0, -1);
return truncateBreadcrumbs(data)
} else {
return data;
}
}
Raven.config('__YOUR_DSN__', {
dataCallback: function (data) {
return truncateBreadcrumbs(data);
}
}).install(); |
|
Edit There isn't much visibility that I could find searching the docs about that option, and that it may be set to false to reduce payload size. It feels like it should be more prominent in your docs. A lot is left to the deduction of the developer. Now to look into how to dynamically send or not send props depending on if the payload size exceeds the maximum. It would be great if there were a third value for @kamilogorek - we're getting this error - the app is intrinsically data heavy. Your code refers to functions that no longer exist. Would I be right in assuming the only thing those non-existent functions do is allow you to encode JSON with circular references? If so, if I were to choose another library and use their stringification function, in place of your old utilities, would your code sample work still? Also, is there a better, built in solution to this? We could probably get away without sending any app state at all, just console log, the error in question and other minutiae. Otherwise errors gobbled up by Vue don't make it up and aren't reported without the Raven/Vue plugin - unless I've setup the Sentry browser client incorrectly. As only an error allow to propagate uncaught appeared in Sentry. Cheers |
@CaelanStewart It does, but here (@sentry/utils package) - sentry-javascript/packages/utils/src/object.ts Lines 109 to 123 in 5d670a7
Kinda, but also some more:
You can investigate vue's context (and optional alter/remove it) with Sentry.init({
beforeSend(event) {
// event.contexts.vue has all the metadata
return event;
}
}) |
Uh oh!
There was an error while loading. Please reload this page.
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.
The text was updated successfully, but these errors were encountered: