New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix update tasks #3958
Fix update tasks #3958
Conversation
a527662
to
dcf7eb9
Compare
Just updated this to fix some of the problems I encountered. Should work now regardless of how you change the schedule. |
celery/beat.py
Outdated
b_model = b.get(name) | ||
if not b_model: | ||
return False | ||
if model.schedule != b_model.schedule: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code looks like it is specific the Django DB models used in django_celery_beat. May not be appropriate to include in celery???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, wait, my objection to my own pull request might be unfounded.
django_celery_beat.schedulers.ModelEntry
is actually inherited from celery.beat ScheduleEntry
- so I am guessing is actually a standard celery object with some extra bits added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the above code is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the record, on this line we are comparing two celery.schedules.schedule
objects (for interval times) or two celery.schedules.crontab
objects (for crontab entries). Or maybe one of each (if the user has just changed from one to the other).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments.
Also, can we add tests for schedules_equal?
celery/beat.py
Outdated
def schedules_equal(self, a, b): | ||
if set(a.keys()) != set(b.keys()): | ||
return False | ||
for name, model in a.items(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think entry is a better name than model. Models are specific to ORMs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, agreed. Probably partly responsible for my confusion above.
celery/beat.py
Outdated
return False | ||
for name, model in a.items(): | ||
b_model = b.get(name) | ||
if not b_model: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need for a separate if statement here. Use or
instead.
celery/beat.py
Outdated
@@ -281,6 +284,17 @@ def tick(self, event_t=event_t, min=min, heappop=heapq.heappop, | |||
return min(verify[0], max_interval) | |||
return min(adjust(next_time_to_run) or max_interval, max_interval) | |||
|
|||
def schedules_equal(self, a, b): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use more meaningful names here. old_schedule and new_schedule works imo.
dcf7eb9
to
e0f4f60
Compare
Have addressed minor issues. Will see if I can do anything about tests. |
In writing a test, I found that when we assign |
Otherwise, if we mutate the dictionary (e.g. using provided methods), we won't see any changes.
Ok, just pushed tests. Have confirmed that the test to check the schedule change works breaks without this change. |
In doing a shallow copy, I am making the assumption that that the I tried using |
It looks like travis crashed before it even got to running the tests. |
@brianmay I restarted the failed job. |
Thanks. Feel free to add yourself to the AUTHORS file. |
Are there plans to get this fix into an official new release soon? |
Yes. It will land on the next release. |
When is the next release due? Are there any obstacles in the way of a release? |
We're working on it. Right now debating about a merged pull request with possible security issues. See celery/py-amqp#146 (comment) |
@thedrow , Looks like the security issue you were talking about is closed. Can we please know when will this fix be released? Thanks. |
I'm trying to reach @ask to provide us with release access. I'll let you know once it happens. |
Hello guys! Thanks :D |
We're unable to reach the maintainer with the release rights. I don't have an ETA for the release. |
@thedrow I assume you mean you can't upload to PyPI? If so, maybe contact PyPI admin and see if they can help? In the meantime maybe you could do the other steps of a release, e.g. use bumpversion to increment the version and add a git tag. Thanks. |
I want this one released so badly |
@sreecodeslayer This was released as part of 4.1.0 a while ago. |
@thedrow , I see that the build has failed. Please check status at https://travis-ci.org/celery/celery/jobs/299003848 for the build at https://travis-ci.org/celery/celery Can you please clarify? |
We're aware that the build has failed. |
In my latest testing, it seems that I still have issues with the schedule not being reloaded in master :-( |
Just set a task to run every 2 minutes. It runs the first time, but then fails to run again until restarting celery. This is with master. Will try downgrading to the most recent stable version and see if that helps. |
Me confused, celery 4.1.0 doesn't seem to be running interval tasks at all. Was working last time I tested it. Will concentrate my efforts on master. |
In master, changing the periodic task to point to a different interval or crontab object results in an instant change, but changing the interval object or crontab itself doesn't. Curious, as this is a case a tested in the pull request. Also the task - if it is an interval - only gets run once. Also curious. |
Oops, just realised a new version of django-celery-beat (1.1.0) was released 13 days ago. Apologies for the noise. The schedule now reloads as required. However I still have this issue where a interval based task only runs once (after restarting task or updating the schedule). |
@brianmay Please open a new issue if one doesn't exist for the problem you are describing. |
@thedrow, ok will do so. |
@brianmay |
#3791 was improved and become #3890. This is an improvement on #3890, as it addresses some of the feedback supplied there.
Checks if the heap is valid. If there are changes in scheduled tasks the heap is populated again.
This means, when using django-celery-beat, changes to the
periodictask
table are automatically detected without restarting celery.Fixes celery/django-celery-beat#7
I can squash/rebase/split/reformat/turn-into-a-penguin as required.