The key phrase from our codebase was:
> # .save() will be called by the caller of this function
But this wasn't the case for the conditionally called path.
Adds data-fixing migration too.
Fix#292
500 was just fine when I was still calibrating the envelope parsing, but AFAICT it's
correct now, so I'd rather not get notified about 'remaining problems' (which are SDK problems)
rather than try-and-recover, just look at the headers and show body/POST etc.
this avoids hard-to-reason about situations where either of those won't work
because the other has already been executed; in combination with reasoning
about max size usage the explicit solution is simply easier to reason about.
further:
* makes api_catch_all one of the content_encoding-ready views.
* implement a max length for the ingest api view
this makes this consistent with the work we did in the previous commit
at the price of being slightly more inefficient.
but it's a deprecated endpoint anyway
Although DIGEST_IMMEDIATELY=True is theoretically a nice thing to
have, the upkeep is not worth it now that we're about to introduce
minidump ingestion.
The only thing that you're saving is the round-trip via the filesystem,
but performance of that is negligable, and if you're configuring
DIGEST_IMMEDIATELY you're actually _not_ in the performance-critical path
anyway.
Getting rid of it _also_ harmonizes/reduces the number of paths to test.
It's approximately 1% of our installed base.
in preparation of the minidump handling through the envelope path,
which probably requires dealing with the whole envelope as a whole.
"theoretically" this might be less efficient, but [a] see the notes
at the top of the parser on how we think about streaming parsing and
[b] the inefficiencies are in the "immediate" path anyway (which has
the assumtion that it's not in high-performance envs).
"blind commit" (tests not run against this commit).
This more exactly expresses semantics by itself, and is also in preparation of
creating releases through the API (which have no triggering event)
See #146
Defends against certain forms of local privilege escalation, i.e.
understood to be defense in depth rather than a security issue given
the recommended ways of deploying (docker container or in a single-use
single-server)
Fix#174
See https://github.com/python/cpython/pull/23901
Using patterns here to play well with our excellent dogfood error
tracker:
When the non-validating value is displayed in the exception value, this makes
grouping not work (every event is its own issue); the approach has no upside,
because in a dogfooded setup the local vars are known anyway.
headers means: envelope headers and item headers.
Provides more robustness and a layer of defense-in-depth
Only those headers that we might rely on in a near future (event-based)
are included.
See #173
