waitForTasksToCompleteOnShutdown has no effect on tasks created with @Scheduled annotation

[stefanocke]

Affects: 2.4.2 (and likely several previous releases)

Steps to reproduce:

1. create a Spring Boot App with Spring Initializr
2. @EnableScheduling at application class
3. create @Scheduled method with Thread.sleep(60000)
4. set spring.task.scheduling.shutdown.await-termination=true in application.properties
5. start the application
6. shutdown the application as soon as it is up

Expected Behavior
The task should not be interrupted, since spring.task.scheduling.shutdown.await-termination sets waitForTasksToCompleteOnShutdown to true on the TaskScheduler.

Actual Behavior
The task is interrupted the InterruptetException is logged.

More Details

• When I manually schedule a task by something like scheduler.scheduleWithFixedDelay(), everything works as expected.
• Debugging shows, that my @Scheduled task is interrupted by ScheduledAnnotationBeanPostProcessor.destroy()
• I also noticed, that this might be intentionally. At least it was in 2016. See for instance SchedulingConfigurer's ScheduledTaskRegistrar should reliably shut down before TaskScheduler [SPR-15067] #19633.
• However, it is at least very surprising, that waitForTasksToCompleteOnShutdown has not the excpected effect on tasks that are created in the somehow "most prominent way", the @Scheduled-Annotation. So IMHO it should either be fixed or documented.
• Moreover, the behavior is inconsistent with @Async : if I create an @Async method and let it sleep for 60000ms while having spring.task.execution.shutdown.await-termination=true , everythinq works as expected: The async task is not interrupted on shutdown.

Note: When I say "shutdown" I mean to stop the application in Spring Tool Suite. In the log I see "Application shutdown requested.", so I assume I am testing an orderly shutdown here and not some corner case.

[savinov]

spring-boot PR related to the issue: spring-projects/spring-boot#15951

[mjaggard]

spring-boot PR related to the issue: spring-projects/spring-boot#15951

Related yes, but doesn't fix this issue - that PR was included in the releases where I've seen this behaviour.

[jhoeller]

This effectively duplicates #31019 and should therefore be addressed as of 6.0.12 / 5.3.30.