You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cloud probe budget test fails when a starved thread pool fires the budget timer late #4741
DarlingCloudIdentityProbeTests.ProbeAsync_NeitherCloudResponds_ReturnsNone_WithinItsOwnBudget failed twice on 2026-09-29. It checks that the probe returns in under 2000 ms when no metadata endpoint answers.
The probe code has not changed since #4330. The test uses a fake handler, so no network is involved. It fails near 2 s, not at random lengths.
What the code does
DarlingCloudIdentityProbe.ProbeAsync(HttpMessageHandler, CancellationToken) makes one linked token source and calls CancelAfter(ProbeBudget), where ProbeBudget is 200 ms.
The EC2 attempt and then the Azure attempt both use that same token. So running the two clouds one after the other does not add up past the budget.
The fake handler waits on Task.Delay(Timeout.InfiniteTimeSpan, cancellationToken), so it ends only when that token is cancelled.
Suspected causes
Thread-pool starvation.CancelAfter fires from a timer callback. That callback needs a free thread-pool thread, and so do the continuations after it. When other tests in the same run block pool threads, the pool adds new threads slowly. A delay of close to 2 s fits that.
A second wait that the probe's token does not bound. Places to look: a retry, TryEc2Async, TryAzureAsync, an HttpClient default. A first read found none, but this needs a careful check.
Steps
Write the test first. Block a set number of pool threads, then run the budget test. Show that it goes past 2 s the same way CI did.
Read TryEc2Async, TryAzureAsync and ReadCappedValueAsync for any wait that budget.Token does not bound.
If starvation is the cause, change the test, not the product. One way is to assert that the handler saw its own cancellation within the budget plus some slack. The other is to move the test into a collection that does not run in parallel.
If the probe has a real second wait, fix the product. Add a Fixed entry to the CHANGELOG.
Once the cause is known, rename this issue after it.
changed the title [-]DarlingCloudIdentityProbe budget test fails near 2 s on loaded runners[/-][+]Cloud probe budget test fails when a starved thread pool fires the budget timer late[/+]on Sep 29, 2026
Activity
[-]DarlingCloudIdentityProbe budget test fails near 2 s on loaded runners[/-][+]Cloud probe budget test fails when a starved thread pool fires the budget timer late[/+]The cloud probe budget test keeps catching waits the budget does not …
The cloud probe budget test no longer fails when the thread pool is s…
erikdarlingdata commentedon Sep 29, 2026
Closed by the watcher: delivered in PR #4754, merged to dev.