When maxTimeMS expires while an operation is queued in an admission::RateLimiter, the interrupted waiter returns its reserved token and releases its queue slot. Under sustained load, another operation immediately occupies that slot and re-borrows the token. Repeated interruption/refund/re-borrow cycles can pin the token bucket’s schedule to one future instant. Replacement waiters then receive different nap durations but the same absolute wake-up time. Up to maxQueueDepth operations may consequently be admitted together, producing a burst far above the configured rate.

Doomed operations should instead wait until their deadline without reserving a queue slot or token, preserving client backpressure without creating synchronized bursts.