@supervacuus Is this an acceptable deviation from the upstream? I understand well it's not good for future updates if the diff grows too much...

Alternatively, we could decide not to support attaching bytes with the Crashpad backend, even though it might get quite confusing to explain the supported vs. unsupported attachment scenarios in the docs. 😅 With this, we would achieve the same level of support for file and byte attachments.

I will give this a deeper inspection tomorrow, but from a quick scan, I wouldn't worry about the diff being unmaintainable. We have already introduced quite considerable changes to Crashpad; Sentry has implemented a significant portion of the current attachment implementation you built on, so modifying attachment behavior is the least of my worries.

The Windows implementation can handle 99MB (Sentry's limit 100MB minus leaving room for other stuff in the envelope/request).

The Linux implementation needs more work. It cannot handle larger payloads than a few hundred KB (wmem_max). I should have tested this earlier...

The Windows implementation can handle 99MB (Sentry's limit 100MB minus leaving room for other stuff in the envelope/request).

The Linux implementation needs more work. It cannot handle larger payloads than a few hundred KB (wmem_max). I should have tested this earlier...

Why not use IPC solely for metadata transmission and do the actual attachment payload transfer via the file system? We already have the buffer in memory on the client side. There is no need to transfer it into the memory of the crashpad_handler.

The fact that we provide a memory buffer interface does not mean the interface towards the crashpad_handler has to be the same. If there is a significant difference between file- and buffer-based attachments, it lies in the point at which the actual data is read. Buffer interfaces will always be eager, and as such, we wouldn't introduce any weirdness by storing them right away.

Why not use IPC solely for metadata transmission and do the actual attachment payload transfer via the file system? We already have the buffer in memory on the client side. There is no need to transfer it into the memory of the crashpad_handler.

Yeah, let's try that. It will make things simpler. I noticed the Crashpad server eventually writes it to the disk together with the crash report anyway.