This ticket added a check to the reconfig procedure that prevents a reconfig to a PSA set that might result in rolling back committed writes. Specifically, given a reconfig to a PSA set, if the user is trying to add a new node, or if the user is modifying an existing non-voting node to make it a voter, we check to make sure the node is not electable and has priority 0 in the new config. If it doesn't, we fail the reconfig.

If the users' reconfig ends up failing because of this check, we should have a Docs page that will guide them in their next steps. The correct procedure involves two reconfigs:

First, do a reconfig to give the added/modified node votes: 1 and priority: 0
Second, do another reconfig to give the added/modified node votes: 1 and priority: 1

Both reconfigs should succeed, and the user should end up in their desired PSA config after this procedure.

Users may also use the new rs.reconfigForPSASet() function in the mongo shell, which will issue both reconfigs automatically. It takes in 3 parameters:

memberIndex: the index of the node being added/modified
cfg: the desired end config
opts: any options to run with both reconfig commands

It is important that users should only use this function if they encounter the check added in this ticket. We will link users to the Docs page in a follow-up ticket, after it has been created.

Thank you, and let me know if I can answer any questions!

In a follow-up ticket, we will link to the DOCS page