When an error occurs on the connection in case of MARS, during the execution of a reader, it forces the connection to be closed. While closing the connection the TdsParserSessionPool is Disposed
During this process of tearing down the connection, the underlying packet is released at https://github.com/dotnet/corefx/blob/e89d17a0a97d5de707f24587118acc8072667b78/src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserStateObject.cs#L2530 when the SNI error is read by TdsParserStateObject
In case of the Native SNI, the packet release also tears down any callbacks that are associated with the packet, and hence the ReadAsyncCallback is never triggered.
In case of managed SNI, the packet release sets the private SNIAsyncCallback _completionCallback
to null.
My fix is to check if the _completionCallBack is null and if it is, then the upstream TdsParserStateobject is not notified of the error via the callback.
The change has been limited to the error handling part where the problems exist. There is no expectation of an unexpected successful callback being triggered after the packet has been Reset.