[CaffeinatedCoder]

Why

16 of the last 80 runs of the test workflow failed. 7 of them failed on tests that check correctness under concurrency but were written against timing: the 500 ms LockTimeout.Default, a fixed Task.Delay, or an upper bound on how late a timer may fire. On a loaded runner (xunit runs the classes in parallel on a few cores, other classes block threads, every class commits to the same disk) they fail with a TimeoutException or a count of zero that says nothing about what they check, and every red check has to be opened to see that the PR is not at fault. Today that is the case for #285, #278, #253, #246 and #245.

Test	Failed runs	What the runner did
CrossCollectionWriteRaceTests.Concurrent_Inserts_Into_Different_Collections_LoseNothing	3 (2 on main)	Timed out acquiring collection lock (Insert): three writers share the file-wide write lock, each holds it through its commit
CdcScalabilityTests.Test_Cdc_Slow_Subscriber_Does_Not_Block_Others	3 (1 on main)	the event was not delivered within the 200 ms Task.Delay
IndexPageReleaseTests.DynamicCollection_DropIndex_WaitsForTheCollectionLock	2	the Task.Delay(100) continuation ran after the drop had timed out at 500 ms
IndexPageReleaseTests.CreateDropIndexCycles_{Typed,Dynamic}_DoNotGrowTheFile	1	Timed out acquiring commit lock (GroupCommit)
ConcurrentConsistencyTests.ConcurrentInsertAndRead_8Threads_NoCorruption	2 (main)	Reader completed 0 reads: the writers finished before a reader task was scheduled
WalLockTimeoutTests.WriteBeginRecord_ThrowsTimeoutException_WhenLockIsHeld	1 (main)	the 100 ms timeout returned after 770 ms (< TestWriteTimeoutMs * 5)
WalLockTimeoutTests.CancellationToken_AbortsBeforeTimeout	1	the 10 ms token lost against the 100 ms timeout: TimeoutException instead of OperationCanceledException

(The other failed runs were PR-specific or are not timing: an oracle seed on #250, Spatial_DeleteHalf_OfASplitTree_ReturnsExactlyTheSurvivors once on #280, and HighContention_ManySmallTransactions_ConsistentFinalState once on main with a document whose t field did not match its collection, which this PR does not touch; see below.)

What changes

No library code. tests/BLite.Tests/LoadTolerant.cs holds what the tests share:

• LoadTolerant.LockTimeout: 30 s read and write. A deadlock still fails the test; a commit waiting for the disk does not. SingleFile and Server(path) are the two PageFileConfig presets with it.
• LoadTolerant.WaitUntilAsync(condition, what): polls every 5 ms for up to 10 s and fails naming what, instead of sleeping a fixed time and hoping the background work is done by then.

Per test:

• CrossCollectionWriteRaceTests opens with LoadTolerant.SingleFile.
• ConcurrentConsistencyTests opens with LoadTolerant.Server; each reader reads at least once (do … while), so the assertion that every reader did work holds whenever the reads were correct.
• IndexPageReleaseTests: the two cycle tests and DropIndex_WaitsForTheCollectionLock open with LoadTolerant.SingleFile. The latter still checks that the drop has not completed after 100 ms while the lock is held, which is true however late the continuation runs.
• WalLockTimeoutTests: the upper bound on a timed-out wait is TestWriteTimeoutMs + 2000, which allows the lateness seen in CI and still tells 100 ms from the 5 s default; the cancellation test configures a 10 s timeout so the 10 ms token wins by a margin.
• CdcScalabilityTests: the slow subscriber blocks on a ManualResetEventSlim the test opens, instead of Thread.Sleep(2000), so "the fast subscriber received the second event while the slow one is still in its first" is a fact, not a race against 200 ms; every wait polls for the delivery it expects. The 1000-subscriber test polls too.

Checked

• The five classes (31 tests), 5 runs in a row with DOTNET_PROCESSOR_COUNT=2 while two full copies of the suite ran alongside as load: 155/155 passed.
• Full suite with the change, two copies at once with DOTNET_PROCESSOR_COUNT=2: 3092 passed, 0 failed, 4 skipped, each in about 5 minutes.

Connected

• The 500 ms default itself: a commit that waits for another commit's disk sync should not be a TimeoutException, and fix(wal): sync the WAL to disk before a commit is acknowledged #280 makes the sync real. Filed as A commit that waits for another commit's disk sync fails with TimeoutException after 500 ms: LockTimeout.Default is tuned for an unsynced WAL #303; this PR deliberately does not change the default.
• test: oracle tests for the LINQ provider and the typed collection store #250 fails on OracleSeedsTests.Seed_AppliesToTheCurrentTree (a seed patch that no longer applies after the restack), which is that PR's to fix.
• Spatial_DeleteHalf_OfASplitTree_ReturnsExactlyTheSurvivors failed once on fix(wal): sync the WAL to disk before a commit is acknowledged #280 (run 39022045597) with one survivor missing from the Within result. 20 runs of that class on main and 20 on the fix(wal): sync the WAL to disk before a commit is acknowledged #280 branch, both under load, all passed; I have no explanation yet and this PR does not touch it.
• HighContention_ManySmallTransactions_ConsistentFinalState failed once on main (run 38749678260) at the field check after FindByIdAsync, not at a timeout. I could not reproduce it in 8 runs under load; it is not a timing assertion and this PR leaves it alone.

🤖 Generated with Claude Code

[mrdevrobot]

Changes requested. The individual changes are sound and the CDC gate is better than the sleeps. But this moves five classes to 30 s locks and leaves the same timeout family in the rest of the suite: under load we still get PageFile write-lock (AllocatePage) timeouts in BTreeSplitTests, BTreeRollbackFreeTests, StringIndexPrefixMatch and others, plus DropIndex_WhileInserting in a class this PR edits. Use one shared load-tolerant timeout for the test suite instead of per-test values, and cover MetricsTests.WatchMetrics_EmitsSnapshots and VacuumTests Spatial_FailedRebuild. Also: the readers' do/while lets "every reader did work" pass on a single read made after the writers finish.