Product

Strawberry Shake

Version

15.1.5

Link to minimal reproduction

https://dotnetfiddle.net/QFg4B6

Steps to reproduce

The repro snippet contains Server+Client side example code.

We did a deep debugging session and cut off every other possibilities (including character encoding, etc.) and found that after the refactor of request/response handling in v15.1.5 causes this issues somehow.

When the CustomAnyCollectionEndpointResult<T>.Items result list contains more than a specific amount of data, the main client deserialization dies (see comment in the snippet for result.Resolve part for details) because it's trying to find backslash escaping (but cannot):
System.ArgumentOutOfRangeException: 'Specified argument was out of the range of valid values.'

 System.Text.Json.JsonReaderHelper.TryUnescape(ReadOnlySpan`1 source, Span`1 destination, Int32 idx, Int32& written)
   at System.Text.Json.JsonDocument.UnescapeString(DbRow& row, ArraySegment`1& rented)
   at System.Text.Json.JsonDocument.WriteString(DbRow& row, Utf8JsonWriter writer)
   at System.Text.Json.JsonDocument.WriteComplexElement(Int32 index, Utf8JsonWriter writer)
   at System.Text.Json.JsonDocument.WriteElementTo(Int32 index, Utf8JsonWriter writer)
   at StrawberryShake.Serialization.JsonSerializer.Parse(JsonElement serializedValue)
   at 

Since the relevant System.Text.Json version didn't change we can only assume that the buffering part is affected in the code change introduced in 15.1.5 and thus the deserializer cannot handle the whole content properly.

What is expected?

Data is read properly like in v15.1.4 with same content without any issues (doesn't matter the size of the returned result)

What is actually happening?

Client cannot read response due to internal serialization error when conditions met (e.g. AnyType-ed result is bigger than a small buffer)

Relevant log output

Additional context

The issues persist in latest stable as well (v15.1.6 when writing the issue).
We included foreign characters in the result content to make sure the UTF8 encoded string contains backslash (\u0...) thus properly represent the case but it probably happens even without those if result data is big enough.

It's obviously an edge case but a very severe given only a patch version changed. Introducing some test cases for this kind of use cases would be very welcomed!