In some replica set environments, the primary catchup period following an election can stall for up the maxTimeMSOpOnly timeout on the preceding replSetRequestVotes op to due to a cancelled callback on a minority of voting members once the new primary reaches a majority of votes to be elected.

This can cause socket exceptions for the connection pool between the primary and the minority members where the callback was cancelled, and blocks heartbeat sync during catchup with the primary until the original replSetRequestVotes op timeout expires. 

This ultimately delays the elected primary from becoming ready to accept new writes for the duration the the op timeout, even though the election vote itself completes within a few milliseconds, as well as primary catchup period once the op timeout elapses.

While disabling or configuring a low catchupTimeoutMillis would unblock this scenario, it comes at the expense of increased rollback risk and is not a preferred option for some highly sensitive environments.

It appears here that the op timeout for replSetRequestVotes is based on the minimum value between maximumVoteRequestTimeoutMS and electionTimeoutMillis.

However, it seems maximumVoteRequestTimeoutMS is a defined constant of 30 seconds. 

I would anticipate that it be an superior option to promote faster failover for this scenario without having to lower the election timeout or skip the catchup period if maximumVoteRequestTimeoutMS was a configurable timeout via a mongod server param or replica-set setting