Skip to content
This repository has been archived by the owner on Oct 23, 2023. It is now read-only.

Errors in requests with large request bodies are silently dropped #302

Open
mhallin opened this issue Mar 30, 2017 · 5 comments
Open

Errors in requests with large request bodies are silently dropped #302

mhallin opened this issue Mar 30, 2017 · 5 comments

Comments

@mhallin
Copy link

mhallin commented Mar 30, 2017

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

Bug

Has someone had this problem before?

Might be related to #153 and https://github.com/taskcluster/taskcluster-lib-monitor/issues/55

What is the current behavior?

We use the Express integration, and when a request with a large request comes in and generates an error, Sentry will return HTTP 413, which in turn makes Raven silently drop the error.

What is the expected behavior?

Anything other than silently dropping an error :) The bare minimum would be to log the error to the console, but it would be nice if it retried sending the error to Sentry but maybe with less contextual information, just to get some information sent.

@LewisJEllis
Copy link
Contributor

Hmm, interesting, thanks for the report. I wouldn't expect the express request body size to affect how big the error report request ends up being, but maybe there's something being included as part of the context that I'm not realizing. I'll try to reproduce, and I'll think about what raven should do with 413s in general.

@mhallin
Copy link
Author

mhallin commented Mar 31, 2017

Looking at it now, the large request body might be a red herring - we might just be straight up rate-limited by sentry.io. Anyhow, it would be neat if Raven would log that fact somewhere.

@clayzermk1
Copy link

I just hit this with a stack trace that was longer than normal. Only the one error should have been triggered so I don't think it's rate limiting in my case.

@benvinegar
Copy link
Contributor

Anyhow, it would be neat if Raven would log that fact somewhere.

Agree with this.

@clayzermk1
Copy link

One issue I found was that an error was setting its statusCode to 403 since it was coming from an API response. For my app, this was actually a critical error. This line in the exception handling middleware was silently passing the error.

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

No branches or pull requests

4 participants