2.1.2: `Expected to read 7907 payload bytes but only received 636`.

Software versions MySqlConnector version: 2.1.2 Server type (MySQL, MariaDB, Aurora, etc.) and version: MySql 8.0.24 .NET version: .NET 5.0

Describe the bug An hour after upgrading from 2.1.0 to 2.1.2, we got flooded with these logs: Expected to read 7907 payload bytes but only received 636.

Exception

at MySqlConnector.Protocol.Serialization.ProtocolUtility.<DoReadPayloadAsync>g__AddContinuation|5_0(ValueTask`1 readPacketTask, BufferedByteReader bufferedByteReader, IByteHandler byteHandler, Func`1 getNextSequenceNumber, ArraySegmentHolder`1 previousPayloads, ProtocolErrorBehavior protocolErrorBehavior, IOBehavior ioBehavior) in /_/src/MySqlConnector/Protocol/Serialization/ProtocolUtility.cs:line 480
   at MySqlConnector.Core.ServerSession.ReceiveReplyAsyncAwaited(ValueTask`1 task) in /_/src/MySqlConnector/Core/ServerSession.cs:line 956
   at MySqlConnector.Core.ResultSet.<ScanRowAsync>g__ScanRowAsyncAwaited|9_0(ResultSet resultSet, Task`1 payloadTask, Row row, CancellationToken token) in /_/src/MySqlConnector/Core/ResultSet.cs:line 252
   at MySqlConnector.Core.ResultSet.ReadAsync(IOBehavior ioBehavior, CancellationToken cancellationToken) in /_/src/MySqlConnector/Core/ResultSet.cs:line 211
   at MySqlConnector.MySqlDataReader.ReadAsync(CancellationToken cancellationToken) in /_/src/MySqlConnector/MySqlDataReader.cs:line 36
   at eyedo.api.agent.EntityHandler.<>c.<<-cctor>b__6_2>d.MoveNext() in C:\Users\Daniel\Desktop\git\eyedo-server\agent-api\Handlers\Entities\EntityHandler_Get.cs:line 621
--- End of stack trace from previous location ---

Code sample I don’t have yet a reproduction code or a sample, as I don’t event know what query triggers it. The stack trace is cut for some reason at the point of application code. Working on it.

Additional context In the meanwhile, we’re reverting to 2.1.0.

[danielgindi]

Nope, I am saying that on 2.1.0 it does not happen… on 2.1.2 it happens. I think that it happens on large columns that are the result of a GROUP_CONCAT

[danielgindi]

Are you essentially proposing that (in this scenario) the library throw a MySqlException (with appropriate ErrorCode) instead of an EndOfStreamException?

It would be best if we can determine the stream end reason. Then if it’s timeout, we could throw a timeout exception like we do anyway when we are not in the middle of a read/write operation. And if it’s a simple cancellation, we could rethrow an OperationCanecelledException