dragonmantank / cron-expression

CRON for PHP: Calculate the next or previous run date and determine if a CRON expression is due
MIT License
4.55k stars 121 forks source link

Hashed cron expression support #155

Open kbond opened 1 year ago

kbond commented 1 year ago

Hello, curious if there's any interest in adding support for "hashed" cron expressions. This is a feature I ported to PHP from Jenkins in zenstruck/schedule-bundle (this link describes the feature).

If interested, how should it be added? One thing it needs is a context string to use to make the resulting expression deterministic:

new HashedCronExpression('# #(0-2) * * #', 'some context');
new HashedCronExpression('# #(0-2) * * #', 'different context'); // generates different expression than above
kbond commented 1 year ago

A great improvement on my code by @TimWolla here: https://github.com/symfony/symfony/pull/49792#discussion_r1156112353!

TimWolla commented 1 year ago

Related: https://news.ycombinator.com/item?id=35862837

kbond commented 1 year ago

Interesting, so for my example above, the new syntax would look like?

new HashedCronExpression('~ 0~2 * * ~', 'some context');

In OpenBSD, I think the time is randomized for each run (not deterministic) or am I wrong on that?

TimWolla commented 1 year ago

Interesting, so for my example above, the new syntax would look like?

Yes, this is my understanding. It would now also allow 0~29/5 * * * * (every 5 minutes during the first half of an hour, but with a random offset of 0-4), whereas your syntax does not allow it to my understanding.

In OpenBSD, I think the time is randomized for each run (not deterministic) or am I wrong on that?

Not sure, I don't use it. I came across the HN submission and thought I'd share it, because it is related.

dragonmantank commented 1 year ago

The problem with "jitter" in this library is that because it has no state, there's no guarantee that a cron will validate, nor to stop it from running multiple times within the jitter window.

In this case, wrapping this library and extending is probably actually the best case. Then an individual task-running system can handle that any way they want (currently cron-expression should just be viewed as a validation tool, not specifically task running).

I'm happy to leave this open if we get a decent traction, because I'm slowly moving things over to phpixie-cron where it will be easier to group more of these over-the-top implementations.

TimWolla commented 1 year ago

The problem with "jitter" in this library is that because it has no state, there's no guarantee that a cron will validate, nor to stop it from running multiple times within the jitter window.

The suggestion would just be an “expression generator” that takes a pattern and a seed and returns a deterministic expression. The purpose would be generating different execution times within a fleet of servers, without storing state.