413 Request Entity Too Large on Breadcrumbs

I encountered 413 responses after enabling the redux integration, as well as separately after manually adding breadcrumbs which may include a large data param.

It seems there is no limit on the field length imposed in the JS library. See here for an example as implemented in the Python library: getsentry/raven-python#1194

An alternative might be to retry with a lower breadcrumb count on 413 failure. The default number of breadcrumbs is 100 (#3038).

See also:
#2798
getsentry/raven-python#604

The 413 Entity Too Large response is triggered when the decompressed event size is larger than 1MB. This is not just the breadcrumbs, but the entire event payload including the stack trace, tags, extra context...

@rbisol

The 413 Entity Too Large response is triggered when the decompressed event size is larger than 1MB.

@rbisol This way makes it very hard to avoid hitting the limit.

The 413 Entity Too Large response is triggered when the decompressed event size is larger than 1MB. This is not just the breadcrumbs, but the entire event payload including the stack trace, tags, extra context...

Def, but it is the breadcrumbs that are unexpectedly large in this case, and pushing the aggregate over the expected limit.

Hi there, I've just encountered this problem myself, and I would like to ask what's the recommended way for an application developer to safely avoid this size limit issue.

I want to check/ask two things:

If the overall request size, in any way, exceeds the limit, the error will not be recorded on Sentry and so the application developers have no way of knowing that the error even happened, is this correct?
If so, is there any hook provided by the SDK, that enables checking the payload size before sending and truncating properties in the case of over limit?

The first impression I had to achieve 2) was to use the beforeSend hook with something like

beforeSend(event) {
    const size = JSON.stringify(event).length
    if(size > PAYLOAD_LIMIT) {
        // do some reduction of the event at the developer's choice
    }
    return event
}

But then, as I've roughly tested on local, although the event argument that beforeSend receives looks identical to the http request payload, the size of the object does not exactly match that of content-length of the request (probably because the actual request contains extra headers), which entails the developer to take the ambiguous (though estimatable) header size into consideration when dealing with the limit.

Am I missing/misunderstanding something here?
Thanks in advance!

This is absurd.. Just trying out Sentry and it didn't even work once because of this...

@yuichkun

Hi, generally I think having a size limit is reasonable.

One thing that comes to mind to resolve your issues would be to either set normalizeDepth, or normalizeMaxBreadth in the init options. Of course, when using either of these options you will lose some event data on the way to sentry - this is simply a tradeoff we have to make to stay below the size limit.

@yuichkun's approach using beforeSend should also work but is more work to configure.

So dropping errors silently altogether is reasonable huh? Ok then..

I used the other issue (#2798) idea:

Sentry.init({
  dsn:
    'dns_url',
  beforeBreadcrumb(breadcrumb, hint) {
    if (breadcrumb.category === 'console') {
      return null
    }
    return breadcrumb
  },
})

@dmvvilela

I agree with @dmvvilela, it would be nicer to raise somewhere something to alert us that the error sending will be dropped due to a payload too large to let us reduce the size of this payload.

Navigation Menu

Repository navigation

413 Request Entity Too Large on Breadcrumbs #3036

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

413 Request Entity Too Large on Breadcrumbs #3036

Description

Activity

rodolfoBee commented on Nov 6, 2020

Sija commented on Nov 6, 2020

Empact commented on Nov 6, 2020

yuichkun commented on Mar 14, 2022

dmvvilela commented on May 11, 2022

lforst commented on May 11, 2022

dmvvilela commented on May 11, 2022

Amatewasu commented on Sep 20, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions