After an election, the majority commit point on the new primary may be stale. This can cause a client that performs majority writes and majority reads with readPreference:"primary" to fail to read its own write after an election.

Customers can work around this issue by using causally consistent sessions, but if the end user may interact with the database through multiple app servers, this requires passing the clusterTime token all the way back to the user's browser/app, which is impractical. It would be preferable if users can get read-your-writes by performing majority writes and majority reads with readPreference:"primary".

One way to solve this is by blocking majority reads on the new primary until it commits its first write in the new term. This might require shortening the time taken to commit the first write in the new term.

Note that even after this issue is addressed, clients that perform majority writes and majority reads with readPreference:"primary" may still fail to read their own writes after an unplanned election, if they are interacting with the database through multiple app servers or mongoses. However, this ticket describes the only known issue caused by planned maintenance, which accounts for the vast majority of elections.