Our previous adjustments to shutdown in a friendlier way for appropriate errors (PDB-4627) ecb22d3a0fc4579d5e94075d57634bdf6df880fa, we ended up deferring some shutdowns that should have been immediate (i.e. if the config were broken). because request-shutdown only initiates the shutdown after all services have finished starting (if none of them throw an exception). This was a problem because the PuppetDBServer was not necessarily left in a consistent state for other dependent services like the command dispatcher.
Since TK doesn't have a way to initiate an immediate friendly shutdown yet, for now just revert to throwing an exception.
Our previous adjustments to shutdown in a friendlier way for appropriate errors (PDB-4627) ecb22d3a0fc4579d5e94075d57634bdf6df880fa, we ended up deferring some shutdowns that should have been immediate (i.e. if the config were broken). because request-shutdown only initiates the shutdown after all services have finished starting (if none of them throw an exception). This was is a problem because the PuppetDBServer was not necessarily left in a consistent state for other dependent services like the command dispatcher.
Since TK doesn't have a way to initiate an immediate friendly shutdown yet, for now, as a mitigation, just revert to throwing an exception make sure we can't come out of maintenance mode during the (deferred) shutdown, until we resolve PDB-4805.