This PR makes any allocations that occur in the decode path fallible, without any public API changes.
The changes are specifically scoped to repeated fields, Vec<u8>, and String.
Repeated fields, before pushing onto the Vec<...> of values, we now call Vec::try_reserve(1) and map the possible TryReserveError to a DecodeError. Reserving for a single element is what Vec already does so there shouldn't be a performance impact, and DecodeError is already opaque so this doesn't change the public API surface.
Vec<u8> and String, these types reserve space as part of the sealed::BytesAdapter::repliace_with trait. This trait method was updated to return a Result<(), TryReserveError> and now will fail if we can't reserve enough space. Given this is a sealed trait there are no public API changes.
In addition to making allocations fallible, I also changed the merge impl of Vec<u8> to use bytes::merge_one_copy like String does, this should result in strictly less allocations.
Why make this change?
Previously users had no way to guard against OOMs in decoding. You could try to make a guess based on the size of the encoded message, but this fairly inaccurate because it would be very difficult (impossible?) to account for things like the ammortized growth of a Vec. Even if you did guess based on the size of the encoded message, there is no way you could account for multiple messages being decoded in parallel in individual tasks, e.g. handling multiple network requests in parallel.
What about the encoding path?
A similar change is not needed for the encoding path because you can already guard against OOMs by using the encoded_len() to allocate a buffer yourself guarding against OOMs, and then encode into this newly allocated buffer.
This PR makes any allocations that occur in the decode path fallible, without any public API changes.
The changes are specifically scoped to repeated fields,
Vec<u8>, andString.Vec<...>of values, we now callVec::try_reserve(1)and map the possibleTryReserveErrorto aDecodeError. Reserving for a single element is what Vec already does so there shouldn't be a performance impact, andDecodeErroris already opaque so this doesn't change the public API surface.Vec<u8>andString, these types reserve space as part of thesealed::BytesAdapter::repliace_withtrait. This trait method was updated to return aResult<(), TryReserveError>and now will fail if we can't reserve enough space. Given this is a sealed trait there are no public API changes.In addition to making allocations fallible, I also changed the merge impl of
Vec<u8>to usebytes::merge_one_copylikeStringdoes, this should result in strictly less allocations.Why make this change?
Previously users had no way to guard against OOMs in decoding. You could try to make a guess based on the size of the encoded message, but this fairly inaccurate because it would be very difficult (impossible?) to account for things like the ammortized growth of a Vec. Even if you did guess based on the size of the encoded message, there is no way you could account for multiple messages being decoded in parallel in individual tasks, e.g. handling multiple network requests in parallel.
What about the encoding path?
A similar change is not needed for the encoding path because you can already guard against OOMs by using the
encoded_len()to allocate a buffer yourself guarding against OOMs, and then encode into this newly allocated buffer.