opened
joelbixbyrevel
username_0
I've noticed that my tasks are scheduled strangely between restarts. For internals, they wait the entire amount of time of the internal.

After digging into the source, I've narrowed down the issue to not reading the meta data from the schedules stored on Redis. `setup_schedule` is currently calling a method `maybe_entry` which creates a new entry with a last_run_at set to the current time.

https://github.com/username_1/redbeat/blob/ff7685f8a199cf6c5e0dc9084ff30a0e14b2f5da/redbeat/schedulers.py#L397

Is it expected that the interval timer would be restarted between beat restarts? or am I correct in thinking that it should factor the last_run_at in from the meta data in Redis after restart.

I did a little research into what the other schedulers are doing and I believe some are taking into account the last_run_at saved in their respective stores. django-celery-beat for example does a `create_or_update` when instantiating the Entry class in the `from_entry` method. That method is very similar to your own `from_key`

https://github.com/celery/django-celery-beat/blob/master/django_celery_beat/schedulers.py#L183-L186

redbeat: 0.13.0
django: 2.2.5
redis-py: 3.3.11
`Entry.last_run_at` Not Respected Between Restarts
issue
created
joelbixbyrevel
username_0
Heres a sample of output:

```
[INFO][celery.beat][2020-02-07T16:18:14.501950] beat: Starting...
[INFO][redbeat.schedulers][2020-02-07T16:18:14.579097] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:18:19.586736] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:18:24.590713] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:18:29.599073] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:18:34.607386] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:18:39.611007] Loading 1 tasks
[INFO][redbeat.schedulers][2020-02-07T16:18:39.624242] Scheduler: Sending due task health check every 30 (revel.common.celery.health_check)
[INFO][redbeat.schedulers][2020-02-07T16:18:44.657929] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:18:49.665227] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:18:54.673581] Loading 0 tasks


[INFO][celery.beat][2020-02-07T16:18:59.274981] beat: Starting...
[INFO][redbeat.schedulers][2020-02-07T16:18:59.346911] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:19:04.350679] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:19:09.357298] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:19:14.361769] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:19:19.365981] Loading 0 tasks
[INFO][redbeat.schedulers][2020-02-07T16:19:24.375015] Loading 1 tasks
[INFO][redbeat.schedulers][2020-02-07T16:19:24.393131] Scheduler: Sending due task health check every 30 (revel.common.celery.health_check)
```
comment
created
sibson
username_1
Without looking too deeply, I suspect redbeat isn't properly handling ```relative``` as defined in https://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html#available-fields.   If that's the case then as you've surmised the usage of last_run_at is problematic.
comment
created
mathieu-lemay
username_2
I don't think it has anything to do with the `relative` property. It's as @username_0 found, when celery beat is started, the schedules are recreated in redis with a `last_run_time` set to now instead of being taken from the data in redis.

So if I have a task scheduled to run every hour that ran 55 minutes ago and I restart celery beat, the task will only be sent again in 1h, not 5 minutes.
comment
created
sibson
username_1
Related? https://github.com/username_1/redbeat/issues/210
comment