fix: discard corrupt cache files instead of OOM looping on them

[lgarczyn]

Header read caps at 64 KB, and the discard log no longer reads the whole file.

One mac dev was stuck at 300+Gb usage because sentry was trying to read aarge corrupted dump

test: cover the corrupt cache discard through SentrySdk.Init

[jamescrosswell]

Hi @lgarczyn - thanks for the contribution.

Could I get a bit of context for this? I don't think any issue was raised. What circumstances were you running into problems? What happens vs what you expect to happen? Is there an easy way to reproduce this?

Thanks in advance.

[lgarczyn]

Hi @lgarczyn - thanks for the contribution.

Could I get a bit of context for this? I don't think any issue was raised. What circumstances were you running into problems? What happens vs what you expect to happen? Is there an easy way to reproduce this?

Thanks in advance.

Hello!

One of our designer's mac computer crashed.

When it restarted, it was extremely sluggish, with insane memory usage.

Trying to debug it, we found out sentry was trying to load a giant log or dmp, failing, and then just trying again.

This is to try and mitigate it

[lgarczyn]

A crash mid-write leaves a big NUL-filled envelope in the cache.

ReadLineAsync has no length cap, so the header read OOMs.

OutOfMemoryException isn't JsonException, so the discard catch never fires

MoveUnprocessedFilesBackToCache starts the loop again the file every launch.

Manual fix: Deleting the cache by hand.

This PR: Cap the header read at 64 KB, route InvalidDataException through the existing discard, and limit LogFailureWithDiscard, so it doesn't try to pickup 100Gb file.

Test: cover the corrupt cache discard through SentrySdk.Init. i didn't try to reproduce an actual OOM, because, tbh, I'm not sure how'd you'd test that.