-
Notifications
You must be signed in to change notification settings - Fork 311
Fix TryReadPlpBytes throws ArgumentException #3470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3470 +/- ##
===========================================
- Coverage 68.86% 58.78% -10.08%
===========================================
Files 280 270 -10
Lines 62417 61877 -540
===========================================
- Hits 42982 36373 -6609
- Misses 19435 25504 +6069
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of minor comments.
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs
Show resolved
Hide resolved
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
fixes #3463
fixes #3385
In the reproduction shared in #3463 multiple reads of text fields are ddone in sequence with different lengths until a particular scenario occurs. The situation that causes the error is that a multi-packet text read completes on the third packet of an async operation and the lengths of the text sections in the packets align such that the third packet completes one text read followed by the another text read from the same packet but for a different column.
This hard to reach set of circumstances causes the read logic to see a text read starting in a ContinueReplay state when another read has finished on the same packet and the error is caused by the first completed read leaving behind the data packet byte count used when it completed.
The fix is much easier than trying to replicate and understand the error. We simply need to clean up the data lengths and buffer when we successfully read a value. I've added this logic to the place where the bug was found and precautionarily to the other place in the codebase that does similar logic (one for bytes, one for chars).
Creating a test and runs quickly enough to be reliable in the CI is prohibitively difficult. I haven't been able to go anything that needs fewer than 1600 iterations of large text reads. In this case I feel that the fix is obvious enough that existing coverage may be enough.
This also removes the asserts pointed out as problematic in #3385 i've reviewed them and they're no longer applicable, they were too stringent for the more relaxed buffer handing used when moving from replay to continue states.
@dotnet/sqlclientdevteam can I get a CI run please
/cc @frankbuckley