I've run into this issue also recently.

It makes sense that Flask doesn't want to cache the unparsed body. This could be really large in the case of file uploads. Triggering the caching is probably not best for all scenarios.

This is working for me right now

# Workaround to allow unparsed request body to be be read from cache
# This is required to validate a signature on webhooks
# This MUST go before Sentry integration as sentry triggers form parsing
@app.before_request
def enable_form_raw_cache():
  if request.path.startswith('/redacted'):
    if request.content_length > 1024 * 1024:  # 1mb
      abort(413)  # Payload too large
    request.get_data(parse_form_data=False, cache=True)

if config.SENTRY_DSN:
  sentry = Sentry(app, dsn=config.SENTRY_DSN, logging=True, level=logging.ERROR)

There might still be a better, more general solution. I'm not sure if the code that captures request.form could just be moved into an after_request and still have the same results?

I don't think the raven client should force buffering of the body. That seems like a terrible idea because this could be (as mentioned) huge.

Just ran into this. It took me a long time to realize that this is what was happening. @mitsuhiko could we perhaps add this issue to the docs in Sentry?

Please add a big fat warning in the Sentry docs, also got bitten by this :/

Also just ran into this. Why does the Sentry SDK need to access request.data or request.form? If the SDK is already accessing the data (and triggering it being parsed into a data structure that is attached the request) then I don't understand how it would be doing much for memory/performance concerns by not cacheing it.

For what it's worth the new sentry-python SDK makes this configurable and generally is less invasive for accessing this information.