https://spruce.corp.mongodb.com/task/mongo_node_driver_next_rhel80_large_Node22_test_9.0_replica_set_83668e620841398713a0fa64b2ed3205fb965152_26_09_07_10_41_28/logs?execution=0&sorts=STATUS%3AASC

[2026/09/07 13:03:25.392]   1 failing
[2026/09/07 13:03:25.392]   1) Client Backpressure (Prose)
[2026/09/07 13:03:25.392]        Test 5: Overload Errors with baseBackoffMS override base backoff:
[2026/09/07 13:03:25.392]       AssertionError: expected 299 to be at least 300
[2026/09/07 13:03:25.392]       + expected - actual
[2026/09/07 13:03:25.392]       -299
[2026/09/07 13:03:25.392]       +300
[2026/09/07 13:03:25.392]
[2026/09/07 13:03:25.392]       at Context.<anonymous> (test/integration/client-backpressure/client-backpressure.prose.test.ts:220:46)
[2026/09/07 13:03:25.392]       at processTicksAndRejections (node:internal/process/task_queues:103:5)

The assertion is an exact lower bound with no tolerance: with jitter pinned to 1 and baseBackoffMS=50, the two backoff sleeps are 100ms and 200ms, and the test requires the measured duration to be at least 300ms. The run came in 1ms short. measureDuration floors performance.now() on both ends, and Node timers run on a millisecond-granularity clock, so two chained setTimeout sleeps can complete marginally under the requested total as measured by performance.now(). The 600ms bound on the previous line (test/integration/client-backpressure/client-backpressure.prose.test.ts:219) can fail the same way. The bound comes from the spec pseudocode (assertGreaterEqual(with_base_backoff_ms_time, 0.3)), so a tolerance fix may belong in the specifications repo as well.