Fixed envelopes with large attachments persist on disk #3328
Conversation
jamescrosswell
changed the title
| @@ -76,6 +76,21 @@ public EnvelopeItem(IReadOnlyDictionary<string, object?> header, ISerializable p | |||
| var value => Convert.ToInt64(value) // can be int, long, or another numeric type | |||
| }; | |||
|
|
|||
| internal long? TryGetOrRecalculateLength() | |||
There was a problem hiding this comment.
I don't understand how we get here or how that fixes the issue - even if it does (which I believe).
The attachment size did not get read correctly from the header? How/why not? Should it have been set in the first place? And if we're recalculating it here, should it not end up being set now?
There was a problem hiding this comment.
I'd put all of that in the details for the issue itself... but I just moved it into the details of this PR.
There was a problem hiding this comment.
So the length ends up in the header during serialization and gets removed during deserialization because of trust-issues. Fair enough.
But is this not a bug in the caching transport then? Should the length not be set back on the header during serialization?
There was a problem hiding this comment.
I'm not trying to bikeshed here, I genuinely don't get how it works.
There was a problem hiding this comment.
Yeah you have to read Matt's PR in order to understand where the length is being calcluated now.
Resolves #3209
Problem summary
This is only a problem when using the
CachingTransport. The issue is in two parts. Firstly here:sentry-dotnet/src/Sentry/Http/HttpTransportBase.cs
Lines 129 to 130 in 59f3164
If the
lengthheader has not been set then the envelope item is not correctly identified as being too big... the result is that we only get an exception when we try to send the attachment in the envelope to Sentry.The second factor contributing to the issue is that when deserializing an envelope from the cache, this header gets removed:
sentry-dotnet/src/Sentry/Protocol/Envelopes/EnvelopeItem.cs
Line 446 in 59f3164