The "commit to the config catalog" phase of the Sharding convertToCapped DDL contains a series of remote writes to the config server, some of which are not idempotent: today, the protection against "replay side effects on node stepdown" is guaranteed by the fact that the first remote write in the sequence is implemented as a transaction, but this exposes the code to potential future regressions.
To avoid this, a simple call to _performNoopRetryableWriteOnAllShardsAndConfigsvr may be added as the first instruction of the phase.
- related to
-
SERVER-86577 DDL coordinators can re-commit their changes in a stepdown
- Closed