[Automated] Update API Surface Area#2
Open
github-actions[bot] wants to merge 1 commit into
Open
Conversation
github-actions
Bot
force-pushed
the
update-api-diffs
branch
from
13f8254 to
4a9cc93
Compare
github-actions
Bot
force-pushed
the
update-api-diffs
branch
from
4a9cc93 to
ac56822
Compare
github-actions
Bot
force-pushed
the
update-api-diffs
branch
from
ac56822 to
b2191b8
Compare
github-actions
Bot
force-pushed
the
update-api-diffs
branch
from
b2191b8 to
73a70c5
Compare
github-actions
Bot
force-pushed
the
update-api-diffs
branch
from
73a70c5 to
9466081
Compare
github-actions
Bot
force-pushed
the
update-api-diffs
branch
3 times, most recently
from
31b6fb8 to
71d9903
Compare
github-actions
Bot
force-pushed
the
update-api-diffs
branch
from
71d9903 to
d6ecb66
Compare
rkargMsft
pushed a commit
that referenced
this pull request
Jun 14, 2026
Three concurrency bugs surfaced by post-PR adversarial review of LocalReminderDeliveryThrottle and fixed with regression tests: 1. Concurrency permit leak when rate-acquire phase throws OperationCanceledException. The rate-acquire call is now wrapped in try/catch that releases the previously-acquired concurrency permit before rethrowing. Under the previous code, every in-flight reminder waiting on a rate token at silo shutdown would permanently consume a concurrency permit. 2. Concurrency permit leak in WaitSemaphoreWithTimeoutAsync when the timeout fires at the same instant the semaphore grants. The previous implementation used a ContinueWith(_ => true) projection that erased the distinction between a successful grant and a cancelled wait; if the delay won the WhenAny race after the grant succeeded, the permit was held but no caller was tracking it. Replaced with a single linked-token CTS that relies on SemaphoreSlim.WaitAsync's documented atomic grant-or-cancel contract. 3. Rate-acquire deadline math used TimeProvider.System.TimestampFrequency to scale seconds-to-ticks while comparing against _timeProvider.GetTimestamp() from a configurable TimeProvider. On platforms where Stopwatch.Frequency differs from the configured TimeProvider's frequency (e.g., Linux, or any test using FakeTimeProvider with a non-default frequency), the WaitWithTimeout rate path would terminate early or hang. Rewritten to use TimeSpan-based comparison via _timeProvider.GetElapsedTime, eliminating cross-provider unit mixing. Regression tests: Cancellation_DuringRateWait_ReleasesConcurrencyPermit verifies #1 by driving the test throttle into the rate-wait state then cancelling. WaitUpTo_OnRateLimitedPath_SkipsWhenWaitExceedsTimeout exercises the corrected #3 deadline path on a FakeTimeProvider. Issue #2 is verified by inspection of the new implementation; the contract is now a direct consequence of SemaphoreSlim.WaitAsync's semantics. All 28 tests (21 unit + 5 cluster integration + 2 new regression) pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
rkargMsft
pushed a commit
that referenced
this pull request
Jun 17, 2026
Three concurrency bugs surfaced by post-PR adversarial review of LocalReminderDeliveryThrottle and fixed with regression tests: 1. Concurrency permit leak when rate-acquire phase throws OperationCanceledException. The rate-acquire call is now wrapped in try/catch that releases the previously-acquired concurrency permit before rethrowing. Under the previous code, every in-flight reminder waiting on a rate token at silo shutdown would permanently consume a concurrency permit. 2. Concurrency permit leak in WaitSemaphoreWithTimeoutAsync when the timeout fires at the same instant the semaphore grants. The previous implementation used a ContinueWith(_ => true) projection that erased the distinction between a successful grant and a cancelled wait; if the delay won the WhenAny race after the grant succeeded, the permit was held but no caller was tracking it. Replaced with a single linked-token CTS that relies on SemaphoreSlim.WaitAsync's documented atomic grant-or-cancel contract. 3. Rate-acquire deadline math used TimeProvider.System.TimestampFrequency to scale seconds-to-ticks while comparing against _timeProvider.GetTimestamp() from a configurable TimeProvider. On platforms where Stopwatch.Frequency differs from the configured TimeProvider's frequency (e.g., Linux, or any test using FakeTimeProvider with a non-default frequency), the WaitWithTimeout rate path would terminate early or hang. Rewritten to use TimeSpan-based comparison via _timeProvider.GetElapsedTime, eliminating cross-provider unit mixing. Regression tests: Cancellation_DuringRateWait_ReleasesConcurrencyPermit verifies #1 by driving the test throttle into the rate-wait state then cancelling. WaitUpTo_OnRateLimitedPath_SkipsWhenWaitExceedsTimeout exercises the corrected #3 deadline path on a FakeTimeProvider. Issue #2 is verified by inspection of the new implementation; the contract is now a direct consequence of SemaphoreSlim.WaitAsync's semantics. All 28 tests (21 unit + 5 cluster integration + 2 new regression) pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.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.
Auto-generated update to the API surface to compare current surface vs latest release. This should only be merged once this surface area ships in a new release.