davsclaus opened a new pull request, #24712: URL: https://github.com/apache/camel/pull/24712
## Summary - Fix `SpringScheduledPollConsumerScheduler` violating the `ScheduledPollConsumerScheduler` SPI contract by scheduling the cron task in `doStart()` instead of `startScheduler()` - Move `taskScheduler.schedule(runnable, trigger)` from `doStart()` to `startScheduler()` with an idempotent guard, aligning with `DefaultScheduledPollConsumerScheduler` - Fix `isSchedulerStarted()` to check actual scheduling state (`future != null && !future.isCancelled()`) instead of executor liveness ## What was wrong The Spring scheduler implementation scheduled the cron trigger unconditionally inside `doStart()`, which is called via `ServiceHelper.startService(scheduler)` **before** the `isStartScheduler()` gate in `ScheduledPollConsumer.doStart()`. This meant `startScheduler=false` was silently ignored — the cron started firing as soon as the route started. This affected file, FTP, SFTP, SMB consumers and `GenericFilePollingConsumer` (`pollEnrich()`) when combined with `scheduler=spring`, as they set `startScheduler=false` internally. ## Test plan - [x] New test verifies `startScheduler=false` prevents polling with `scheduler=spring` - [x] Existing `FileConsumerSpringSchedulerTest` still passes (normal scheduling works) Follow-up: [CAMEL-24079](https://issues.apache.org/jira/browse/CAMEL-24079) — Quartz scheduler has the same structural pattern. _Claude Code on behalf of davsclaus_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
