-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Implements a task scheduler for resumable potentially long running tasks #15891
Conversation
1c980d4
to
7c49b15
Compare
7a2a044
to
1d29dcd
Compare
d37e2ec
to
527d442
Compare
527d442
to
470f385
Compare
Out of curiosity -- is there a hope / plan that it might be useful for other tasks in the future? Should we be moving other things to this? |
@@ -0,0 +1 @@ | |||
Implements a task scheduler for resumable potentially long running tasks. |
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 don't think this needs to be a feature -- it is something internally used by Synapse; admins and end-users don't care.
We could probably just combine this with the other PR?
I'd find it very helpful to see how this would be used in the other PR! |
Background DB updates could (should ?) probably be port to this later on. I haven't checked the details of that however.
I am working on this right now since it is also a nice way to validate this works and is enough at least for this use case. This PR will probably get a follow-up update following me trying a real use case. |
I'm putting this back in the overall review queue as it is a hefty chunk of code that I think could use a secondary review. |
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 most of this seems relatively sane, but is missing a big docstring somewhere about how it all works? It might also help if you could point to a usage of this to see how it is to use?
params TEXT, | ||
result TEXT, | ||
error TEXT | ||
); |
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.
Do we want to add some indices for the various fields here? Or is the assumption that this is going to be low volume?
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.
It should be low volume. But then an indice doesn't cost much in space so perhaps we should still do it ?
I am going to add one at least on status
, since this one is used in the reconcile loop and run every 5mn.
resource_id
and action
would help for get_tasks
but I feel they are perhaps less important.
Big docstring is for today ;)
My purge PR has been updated a while ago to use it. |
The non-resolved comments are waiting for ACK/feedback, I think we should be really close to merging :) |
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 this works, just have a query around worker support and a suggestion for improving the DB API a bit
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.
Woo!
I don't think has caused any actual issues. Introduced in #15891
I don't think has caused any actual issues. Introduced in #15891
I don't think has caused any actual issues. Introduced in #15891
The main purpose is to have resumable tasks, with state stored in the DB and the tasks being resumed after a synapse restart.
This is intended to run potentially long running tasks, and be able to schedule them roughly in the future.
This is NOT intended to precisely schedule tasks. The loop is currently running every minute so this is the max granularity we can have, and tasks can be postpone if the running queue is already too big.
This is kind of a spinoff of #15488 following the reviews, which currently implements something similar in a non generic way. I plan to rebase it on top of this framework.
Pull Request Checklist
(run the linters)