Repository navigation
[Bug]: Intermittent test failure for in SuspendNotificationsFixture #1131
Description
Specifically, the newly-added test ConcurrentSuspendDuringResumeDoesNotCorrupt.
Given that this test seeks to force two methods to run concurrently, I think the main problem is that it's being allowed to run in parallel. That is, when running the test by itself, it fails nearly every time, but when running as part of the full suite, it tends to often pass. Which makes sense, because if the ThreadPool is being saturated by all the other tests running in parallel, it drastically reduces the likelihood that the two parallel Tasks that get scheduled don't actually get scheduled concurrently. The Barrier being used here only increases the likelihood that the meaningful units under test get scheduled concurrently, by making sure they wait for each other to be read, but it doesn't actually guarantee concurrent scheduling.
The biggest thing we can do is move this test into a separate fixture and disable parallelism. Which we should probably also do on a LOT of other concurrency tests.
Also, this does seem to be a legit defect in ResumeNotifications(). SuspendNotification()s locks on all the state its modifying, but ResumeNotifications() doesn't.
Activity
Fixed that `ObservableCache.SuspendNotifications()` uses a `lock` to …
Deliver resumed notifications off the lock, closing the #1131 race wi…
Fixed that `ObservableCache.SuspendNotifications()` uses a `lock` to …
Deliver resumed notifications off the lock, closing the #1131 race wi…
Fixed #1131 - Race condition between `SuspendNotifications()` and `.R…
github-actions commentedon Aug 11, 2026
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Fixed #1131 - Race condition between `SuspendNotifications()` and `.R…
Fixed #1131 - Race condition between `SuspendNotifications()` and `.R…
Fixed #1131 - Race condition between `SuspendNotifications()` and `.R…