feat(native): add a compressed minidump endpoint example #11304
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
|
I added @markushi and @JoshuaMoelans since the basic compressed example is relatively simple, but adding meta-data is quite involved. I would love to know if the steps and reasoning are understandable, provided the user is technically sophisticated enough to use |
Co-authored-by: vivianyentran <20403606+vivianyentran@users.noreply.github.com>
Co-authored-by: vivianyentran <20403606+vivianyentran@users.noreply.github.com>
Bundle ReportChanges will decrease total bundle size by 15 bytes (-0.0%) ⬇️. This is within the configured threshold ✅ Detailed changes
|
|
|
||
| # Add additional data via JSON or using the bracket syntax (the latter requiring a field for each entry) | ||
| printf -- 'Content-Disposition: form-data; name="sentry"\r\n\r\n' >> multipart_body.txt | ||
| printf -- '{"release":"my-project-name@2.3.12","tags":{"mytag":"value"}}\r\n' >> multipart_body.txt |
There was a problem hiding this comment.
My first time going through these steps I didn't change this "release" to the actual version that the .dmp file was built for, which I think is the reason I got an {"detail":"invalid minidump"}% result.
Not sure if the advanced users that would use this method of sending minidumps would make the same mistake, but still might be something worth highlighting.
Other than that, these instructions seem fine as a beginner's guide.
There was a problem hiding this comment.
My first time going through these steps I didn't change this "release" to the actual version that the .dmp file was built for, which I think is the reason I got an
{"detail":"invalid minidump"}%result.
The main reason you could get an "invalid minidump" (besides the obvious attaching an invalid minidump file 😅) is probably due to bad escaping or delimiting characters because those could prevent the receiving parser from "seeing" the minidump field.
Correctly formed meta-data shouldn't affect the validity of the minidump (i.e., Sentry doesn't cross-check the release in the sentry field with the contents of the minidump).
This is why documenting this as a solution is a double-edged sword. Manually constructing a multipart body can quickly introduce encoding errors like turns out I used ” instead of ". Thankfully, that error appeared when parsing the JSON metadata (with a slightly better error message).
But if the encoding error appears beyond the field value boundary (forgetting the correct number of \r\n and similar), you might get the results of a wrongly parsed HTTP request.
I think the best solution to the problem would be to let relay
- check if the file uploaded as
upload_file_minidumpis agzipand in that case - unzip the file and then validate it as a minidump and continue processing as it does now
This would allow users to apply the same upload methods as described in the previous sections, but instead of uploading a mini.dmp, they would upload a mini.dmp.gz (identified via the first n-byte header).
Until that solution is implemented and deployed, users have a documented approach for uploading minidumps manually.
|
Following the conversation here: #11304 (comment) I created a Relay-PR (getsentry/relay#4029) that would reduce this documentation change to:
Let's wait before merging if the Relay folk consider this a sensible idea. |
DESCRIBE YOUR PR
The docs currently do not describe how the minidump endpoint can be used when sending compressed payloads. This is often necessary when customers produce minidumps bigger than our upload limits.
Fixes #7575.
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes: