this code was created in a REPL/ChatGPT/minidump-API/HITL session,
until I had something that "seemed to work". the present commit
is the result of rereading, refactoring for understanding etc.
it's not "pure refacting" in the sense that it's behavior-changing,
but AFAICT for the better. e.g. "line 0" => just leave that out and
many similar changes.
(the now-removed 'treat as pid' was hallunicated by the bot; the
taken-from-sentry version missed the guard against -1)
> The index of the thread that requested a dump be written in the
> threads vector. [..] If the dump was not produced as a result of an exception
> [..] this field will be set to -1,
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
for each bundle upload both the chunks and the zipped bundle
were kept (even though they are only needed on-upload, i.e.
after extracting we deal with the extracted files exclusively
This is an important step in 'keeping sourcemaps-related data-usage limited'
i.e. see #129
chunk_upload is and has always been working 'for real'. The only sense in
which the comment has been 'vaguely in the direction of truth' was that
with a chunkSize and maxRequestSize of 32MiB in practice sourcemap uploads
will often have been single-chunk in practice.
See #147
i.e. update the comments to reflect what I just learned doing some actual
experiments.
See #147
b.t.w. the now-removed comment was somewhat misleading: "single-chunk"
was (and is) being forced as in "single chunk per request" but not as
in "single chunk per file", and it was only forced by chunksPerRequest=1,
not by concurrency=1.
As per the comment.
Since we haven't actually gone multi-chunk, this is just preparation
The now-removed comment should be read as 'it could be assumed that
unzipping introduces a factor 5 increase between chunk size and file
size' but that's a whole bunch of assumptions that I'd rather get
rid of (mental overhead, with little gain).
See #147
I did not do any research into actual timings (i.e. whether there really is a
need to pull this out of the request/response loop) but it seems somewhat
prudent. Because Sentry also does this (and does it at this point), the whole
thing of matching Sentry's interface is not being complicated by it (if
anything: the contrary).
