(chore): update claude - #552
Merged
Merged
Conversation
…ests PR #552 CI failed on TimeoutAfter_GenericTask_ShouldPropagateFaultedSourceException_WhenSourceFaultsLater with "Expected a <System.InvalidOperationException> to be thrown, but found <System.TimeoutException>". The PR diff is documentation-only; the defect is a pre-existing race in the test, not a regression introduced by the change. The four source-completes-later tests build the TimeoutAfter proxy with a 100 ms timeout and then complete the source on the very next statement. That arms a 100 ms timer whose callback calls TrySetException(TimeoutException) on the proxy. Whichever of the timer callback and the source completion arrives first wins the proxy. Under the CI runner's parallel execution plus coverage instrumentation the runner thread was preempted for longer than 100 ms between the two statements, so the timer won and the proxy surfaced TimeoutException. Fix: replace the 100 ms literal with NonElapsingTimeoutMs (int.MaxValue). The value stays finite, so TimeoutAfter still builds the proxy and exercises MarshalTaskResults rather than short-circuiting on Timeout.Infinite, but the timer cannot elapse during a test run. No assertion is weakened, no sleep or retry is introduced, and production TimeOutTask.cs is unchanged - its timeout-versus-completion race is correct behavior. Verification: the failure was reproduced deterministically by temporarily inserting a 300 ms stall between proxy creation and source completion, which produced the exact CI error; with the fix in place and the same stall, the test passed. The stall was removed before commit. Full toolchain clean in a single pass: csharpier format/check, msbuild /t:Rebuild with analyzers and code style, msbuild /t:Rebuild with TreatWarningsAsErrors, and the full MSTest suite with coverage (6435/6435 passed). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…r seam Replaces the previous commit's int.MaxValue timeout constant, which removed the observed flake by making the timeout window enormous rather than by controlling time. That is a magic-number workaround, not determinism infrastructure, and it does not satisfy the general unit test policy requirement that async tests use a fake-timer facility to advance simulated time deterministically. TimeOutTask.TimeoutAfter arms the timeout with new Timer(...) directly, so there was no seam a test could control. This adds one, matching the pattern already used by UtilitiesCS/Threading/ThreadMonitor.cs in the same folder: both TimeoutAfter(Task<TResult>, int) and TimeoutAfter(Task, int) take an optional TimeProvider that defaults to TimeProvider.System, and the timer is created via TimeProvider.CreateTimer instead of the Timer constructor. Microsoft.Bcl. TimeProvider is already referenced by UtilitiesCS and Microsoft.Extensions. TimeProvider.Testing by UtilitiesCS.Test, so no new dependency is introduced. The parameter is optional, so all existing call sites are unchanged and production behavior is identical. The four source-completes-later tests now pass a FakeTimeProvider that is never advanced. The timeout timer cannot fire, so the source result is provably the one marshalled to the proxy rather than merely probably so. Two positive-control tests are added that advance the fake clock past the deadline and assert the proxy faults with TimeoutException; without them a mis-wired seam that never armed the timer would pass unnoticed. Full toolchain clean in a single pass: csharpier check, msbuild /t:Rebuild with analyzers and code style, msbuild /t:Rebuild with TreatWarningsAsErrors, and the full MSTest suite with coverage (6437/6437 passed, up two for the new controls). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.