-
Notifications
You must be signed in to change notification settings - Fork 313
Tests | Active Issues 1 #3494
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
Tests | Active Issues 1 #3494
Conversation
…ocked by #5540 Most of the issues with it were debug-only tests that checked async behavior. Async read task was expected to throw, but was simply being waited, causing the test to fail. Fixed by replacing waits with checks for exception (as was used in a handful of similar tests). One issue was due to a debug assert failing in the TDS state object. It's really buried in timeout code, so I have no idea what it's expected to do. However, the code immediately after it was flagged by my IDE as always being true due to the debug - why are we conditionally executing code if we expect it to always be a certain value? So, I removed the debug assert. Also added a handful of todo notes to the test class because it needs breaking up. And it's full of smelly Thread.Wait code.
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.
Pull Request Overview
This PR re-enables the DataStreamTests.RunAllTestsForSingleServer_TCP
test that was previously disabled due to issue #5540. The changes address async operation handling issues in Debug mode and resolve test stability problems.
Key changes include:
- Removing the
[ActiveIssue("5540")]
attribute to re-enable the disabled test - Updating async task waiting patterns to properly handle expected exceptions
- Removing a problematic Debug.Assert that was causing failures in test scenarios
- Removing an entire test file that appears to be no longer needed
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
DataStreamTest.cs | Re-enables TCP test, updates async exception handling patterns, removes failing test method |
AsyncTest.cs | Complete file deletion of async performance test |
Microsoft.Data.SqlClient.ManualTesting.Tests.csproj | Removes reference to deleted AsyncTest.cs file |
TdsParserStateObject.cs | Removes Debug.Assert that was failing in test scenarios |
Comments suppressed due to low confidence (1)
src/Microsoft.Data.SqlClient/tests/ManualTests/SQL/DataStreamTest/DataStreamTest.cs
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/tests/ManualTests/SQL/DataStreamTest/DataStreamTest.cs
Show resolved
Hide resolved
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
- Updated loop to read XML results correctly.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3494 +/- ##
==========================================
- Coverage 68.86% 64.51% -4.36%
==========================================
Files 280 276 -4
Lines 62417 62582 +165
==========================================
- Hits 42982 40372 -2610
- Misses 19435 22210 +2775
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:
|
Description
Re-enables DataStreamTests.RunAllTestsForSingleServer_TCP previously blocked by #5540
In Release mode, it works just fine without any changes. In Debug mode, though, it has issues with async behavior. The test harness for async test created (but did not start) an async operation, attempted to run the operation in parallel (which should fail as another async operation is in progress), then disposes the test harness and waits on the first async task. This fails because the connection is closed when the test harness is disposed, failing the test. It's unclear to me why the test harness disposes the connection or why it exists at all, but that's not the point. So, to resolve those issues, I followed a pattern used in another part of the test code that asserts the final wait throws. Totally unnecessary imho, but if we have to wait something that'll throw, then we might as well make sure it throws.
Another issue happens deep in the TdsParserStateObject in Debug mode. There is a Debug.Assert in there that validates the previousTimeoutState is Stopped. This check is failing in the test scenarios. However, immediately following the assert, we have an if statement that checks the exact same thing. Theoretically if the assert is correct, we always run the code in the if statement. But, since we have the conditional, we must expect that the asserted condition might not be met. It implies to me that the assert shouldn't exist. So I removed it and the test now passes.
Since this is a lengthy explanation, I figure I should submit this PR by itself.
Issues
#5540 - which I don't think exists in GH.
Testing
Running the test locally, it passes