As determined in BF-22420, there is a possibility that WaitForMajorityService will call waitForWriteConcern on a request that has been cancelled but has not been removed from its request collection yet.

The service uses two background threads: one for processing requests (by waiting for replication) and the other for removing requests whose futures have been cancelled.

This behavior can manifest if the cancelled request is at the front of the queue and the processing thread wakes up and acquires the mutex after the cancellation thread has marked the request as processed but before it has removed it from the collection.

While the behavior itself is not a bug, it does cause problems in WaitForMajorityServiceTest where test logic assumes that the request has been handled only once. For example, CancelingEarlierOpTimeRequestDoesNotAffectLaterOpTimeRequests calls finishWaitingOneOpTime twice and assumes that the first request will have been processed after the first call and the second after the second call.

One way to fix this would be to call getLastOpTimeWaited after finishWaitingOneOpTime and retry when necessary.