A recent case in Spring Integration and scenarios as shown in #32109 suggest that we should revisit our default lifecycle phases: currently Integer.MAX_VALUE for ThreadPoolTaskScheduler which leads to it being in the first round of stopping, not giving other tasks room for a custom phase earlier than that without tweaking the scheduler's own phase definition. Also, the default timeout for a lifecycle phase is 30 seconds which seems long (in particular in common cloud deployment arrangements) if you may actually plan to run into this in certain scenarios.
Comment From: jhoeller
ThreadPoolTaskScheduler and co use a default phase of Integer.MAX_VALUE / 2, aligned with Spring Integration.
The default timeout for a lifecycle phase is 10 seconds now.