You are right that Scheduler in stateful mode only works correctly with non-expiring cache.

Option 3 of your suggested solutions would sound the best to me, though I'm not super familiar with the cache component and the behavior of different implementations/providers.

Of course cache by definition is usually considered something you can clear any time without affecting business logic – which brings up the question: is using cache for the Scheduler state a good idea in the first place.

Of course cache by definition is usually considered something you can clear any time without affecting business logic

This is a good point. I guess the simplest solution would be to configure it to use a scheduler-specific cache.

Good find, I would agree that this could be improved. I am looking into the different proposed solutions. Some thoughts:

1. The logic that causes the message to not be yield, is here https://github.com/symfony/symfony/blob/7.1/src/Symfony/Component/Scheduler/Generator/MessageGenerator.php#L72. It's not yield because the fact that the scheduled-time is before the checkpoint means that another scheduler process should have picked it up, hence the Checkpoint has passed it. The other part is the Checkpoint that sets its own $time from cache (also on miss). I guess this also cannot be removed because if the cache has been intentionally reset, you'd want it to start from $now. Though it could become a configurable option, like reset_on_cache_miss.
2. This could be interesting. I don't think it has to check the defaultLifetime. Instead the Checkpoint could warn/throw when a cache was previously hit AND a cache miss occurs. Because this either means: a TTL caused the cache to reset (possibly undesired) or the cache has been reset manually on purpose. To still support the latter option, maybe a configuration value can be introduced: throw_on_cache_miss.
3. This would remove the ability to still use a TTL. I think it still has a usecase: when you want a maximum time for the scheduler to be offline after which it should not resume from so long ago.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

yes this bug still relevant.

I am completely new to the subject of schedulers and may have a few problems understanding them, but according to Messenger: Deploying to Production it makes no sense to define long time intervals with the current behavior.

Don't Let Workers Run Forever
Some services (like Doctrine's EntityManager) will consume more memory over time. So, instead of allowing your worker to run forever, use a flag like messenger:consume --limit=10 to tell your worker to only handle 10 messages before exiting (then the process manager will create a new process). There are also other options like --memory-limit=128M and --time-limit=3600.

Maybe there is a solution using some cache, which fixes #58124 at the same time. Or alternatively a --date parameter like in debug:scheduler command for messenger:consume, which then processes outdated jobs first. So it is possible to implement a cache by yourself.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

still a bug.

Same here. Any update planned soon?

@upgrader-dev Someone would need to work on it and submit a pull request. Would you be interested in giving it a try?

Thank you but I'm just a beginner with Symfony. I'll give it a try anyway.