Allow MIME detection for crashpad attachments in the backend

[Kobby-Bawuah]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

Attach a JSON file and try to view it within the issue page. The preview option is greyed out with the text: Attachment cannot be previewed

A user got around this by adding contentType.
It's a property on the attachment object
const filename = 'XXX.json';
const contentType = 'application/json'; // helps show Preview in Sentry
hint.attachments = hint.attachments || [];
hint.attachments.push({ filename, data, contentType });

We should try to derive the content type from the file name.

Expected Result

Can view the payload in the issue.

Actual Result

Product Area

Issues

Link

No response

DSN

No response

Version

No response

[getsantry]

Routing to @getsentry/product-owners-issues for triage ⏲️

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[rodrigo-vilela-pdfpro]

Hi @Kobby-Bawuah as instructed by you via support ticket email I'm adding-on to this ticket. My team is experiencing the same issue when trying to preview attachments. Here is the content of the ticket I have created:

---

I'm reaching out because my team have been encountering an issue with the Sentry platform.

Specifically, we are unable to preview .txt and .log files at the attachment section of an issue.

Steps to Reproduce:

1. Log in to the Sentry platform.
2. Navigate to an issue and go to the attachment section
3. Attempt to preview the a file by clicking on the preview button.

Expected Behavior:
I expect to be able to preview .txt and .log files directly within the Sentry platform.

Actual Behavior:
When attempting to preview .txt and .log files, I encounter an issue, and the preview does not load.

Additional Information:

• We have tested this on multiple browsers to rule out browser-specific issues.
• We have tested .txt and .log files, both could not be previewed.

Issue URL: https://pdf-pro-software-inc.sentry.io/share/issue/343f0f0abc474a21b1a8145c92fbf3a3/

Submitted from: https://pdf-pro-software-inc.sentry.io/issues/4948032816/?environment=production&project=4506230532734976&query=is%3Aunresolved&referrer=issue-stream&statsPeriod=14d&stream_index=0

Attachment(s)
Sentry_issue_no_preview.png
attachment_cannot_be_previewed.png

---

[roggenkemper]

thanks for the thorough message @rodrigo-vilela-pdfpro. I'm looking into this problem now, but does adding in the contentType like Kobby mentioned in the original message help solve the problem?

[rodrigo-vilela-pdfpro]

Hi @roggenkemper, sorry for the delay on answering here.

We have checked the suggested approach and we do not see how we can set content type for crash reports attachment, there is no such API in sentry.h. We have tried to set it in the Sentry SDK source code, we tried to change "application/x-sentry-envelope" to "application/json", but that did not help. See: https://github.com/getsentry/sentry-native/blob/master/src/sentry_transport.c#L8

Interestingly enough, we have identified that it is possible to preview attachment for custom error events, but not for crash reports. Here is an example of this:

• Crash: https://pdf-pro-software-inc.sentry.io/issues/5017936517/?environment=production&project=4506230532734976&query=is%3Aunresolved&referrer=issue-stream&statsPeriod=14d&stream_index=1
• Custom event: https://pdf-pro-software-inc.sentry.io/issues/5011073138/?environment=production&project=4506230532734976&query=is%3Aunresolved&referrer=issue-stream&statsPeriod=14d&stream_index=0
• Quick video: https://github.com/getsentry/sentry/assets/159082464/3eebf08f-989a-40ab-8534-cc1182978c31

Additional info from our side:

• We use Sentry native SDK version 0.7 (current latest) in C++ app for Windows

Could you guide us on the specific changes needed in the Sentry native SDK for crash reports to enable the preview feature?
Can this adjustment be incorporated in the next Sentry native SDK update?

[malwilley]

@rodrigo-vilela-pdfpro thanks for following up with all this information!

It looks like the native SDK might have a gap here. I'll transfer this issue to that repo and see if the folks there can help.

[Swatinem]

We have checked the suggested approach and we do not see how we can set content type for crash reports attachment, there is no such API in sentry.h. We have tried to set it in the Sentry SDK source code, we tried to change "application/x-sentry-envelope" to "application/json", but that did not help. See: https://github.com/getsentry/sentry-native/blob/master/src/sentry_transport.c#L8

You are right, there currently is no API to set an explicit content-type for attachments.

Also the code you pointed to is completely different, and you should not change the application/x-sentry-envelope value.

An envelope includes all the metadata related to an event, with different items. Things like the event JSON payload, attachments, sessions, etc.

That being said, attachments are very bare-bones right now, and only really have a file path you register them with and thats it. Adding more metadata to it is possible, but would either inflate the API surface by adding new functions, or a breaking change which is a lot less likely.

[supervacuus]

This is a direct result of #894

Adding interfaces is the right choice here, but we also need to extend crashpad, which currently doesn't support attachment content types being passed to the handler.

cc: @kahest (prioritization?)

[kahest]

Closing this as the work required to fix this is captured in #894 - which currently has medium priority, but we'll revisit if we want to bump prio.

[supervacuus]

@kahest The relevant part of this particular issue is that seemingly, for regular events, there seems to be some kind of content-type/mime-type detection in the backend that automatically assigns the type (according to file-extension?), but not for minidump events.

[kahest]

@supervacuus I see - does it make sense to track this in this issue separately?

[supervacuus]

I think it does because it means that our attachments are generally MIME-detected and don't require our users to provide a content type manually.

The other ticket might still make sense for the latter, but I think most users would be happy with the MIME detection in the backend if it actually runs rather than having to provide a content type for each attachment. So, #894 is more work and a less valuable feature.

So, the issue boils down to:

• why don't we get the MIME detection for crashpad events?
• is it because the crashpad_handler does something wrong when attaching to multipart?

I know that the crashpad_handler sends all attachments as application/octet-stream while we do not add any Content-Type header to the envelope items that are attachments. So removing the Content-Type from the attachments sent from the crashpad_handler could do the trick.

Also, after a quick search in the backend, it seems like an attachment without a Content-Type header is the correct discriminator for automatic detection (cc: @Swatinem):

https://github.com/getsentry/sentry/blob/baaf0f404af0229334691f1ed4701950600f0de8/src/sentry/api/serializers/models/eventattachment.py#L39-L43

https://github.com/getsentry/sentry/blob/42050bfa4f3fcc6b19c9f104eba868dcc8535eaa/src/sentry/models/eventattachment.py#L184-L187

I have no way of seeing how attachments are processed, though, so I would need support from an employee when testing this.

If it turns out we can fix this at that point, I think it would be an extremely valuable fix and little effort.

[kahest]

As discussed:

• Can we strip out the application/octet-stream? (in Relay or Crashpad handler)
• Would this make automatic mime type detection work?

Next step: Let's adapt Crashpad handler and test this locally

[kahest]

related Relay PR: getsentry/relay#3225

[aallrd]

Hello,
I bumped into this issue playing with the sentry_options_add_attachment() API to send an AddressSanitizer log file with the minidump.
I tried to add the .txt extension to the file name but the preview button was still greyed out in the UI.
I guess it would need to be sent with the text/plain contentType.

[supervacuus]

Hi @aallrd, We are currently working on integrating a change to the pipeline that would let attachment MIME detection run in the backend without you having to specify a content type in the SDK or change the file extension.