Background

Both issues came up in review comments (Copilot) on a PR that made ReplicationCoordinatorExternalStateImpl::_workerPool a const std::unique_ptr[ThreadPool] constructed in the constructor via makeReplWorkerPool(). They have not been independently verified, so this ticket is to confirm whether they are real and decide on fixes.

Issue 1: Pool can be resized after replication shutdown

• getDbWorkThreadPool() now stays non-null after _stopDataReplication() has shut down and joined the pool. Previously it returned null after stop.
• The runtime-parameter callback for replWriterMinThreadCount treats a non-null pointer as live and calls setMinThreads().
• After shutdown the pool is in shutdownComplete state with zero workers. A positive minimum may make setMinThreads() loop forever, because _startWorkerThread_inlock() refuses to create workers.
• To investigate:
  • Can this hang be reproduced, for example by setting replWriterMinThreadCount after stepping through _stopDataReplication()?
  • Does this affect master only, or also branches where the pool is nulled on stop?
  • Preferred fix: restore null-after-stop, or have setMinThreads()/the callback reject or ignore updates once the pool is shut down.

Issue 2: Pool starts eagerly for every external-state object

• makeReplWorkerPool() calls pool->startup() before returning (oplog_applier.cpp:179-181).
• Constructing it in the ReplicationCoordinatorExternalStateImpl constructor starts the pool for every instance. That includes the temporary instance created by rs.initiate (repl_set_commands.cpp:354), which never starts replication.
• To investigate:
  • Are idle worker threads actually spawned in this case (note minThreads behavior), and what is the practical cost?
  • Should pool creation and startup be deferred until the replication lifecycle starts, or should there be a non-starting factory for construction-time ownership?