In PeriodicRunnerJobAbortExpiredTransactions::_init, we make a shared pointer to a PeriodicJobAnchor and set it on a member variable of the class. Then, we copy that shared pointer into a lambda that gets passed to the TransactionParticipant. If an exception is thrown in the TransactionParticipant code, the desired effects of that function may not have occurred, and we will leave the shared_ptr set on the PeriodicRunnerJobAbortExpiredTransactions object. This means if we were to swallow the exception and retry the _init function, it would see the set shared_ptr and return early. I don't believe any calling code currently would do that, but I also don't see anything stopping or discouraging that pattern, and it has the effect of leaving the object in an unrecoverable partially-initialized state.

Consider rewriting the function such that it constructs the shared_ptr on a local variable, copies that local variable to the lambda passed to the TransactionParticipant, and then sets the shared_ptr onto a member variable as the last step of the function. That way, any exceptions thrown in the _init function have the result of implicitly destructing all the incrementally built state and reattempts of _init have the effect of retrying the entire procedure.