-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Implementing task subscription filtering #11805
Conversation
b7b2038
to
88e9415
Compare
✅ Deploy Preview for prefect-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
) | ||
|
||
if not task_runs: | ||
winner, *placers = finishers |
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.
🥇
@@ -127,9 +122,7 @@ async def test_scheduled_tasks_are_enqueued_server_side( | |||
task_run: TaskRun = await foo_task_with_result_storage.submit(42) |
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.
we shouldn't have to await this but that's because the _create_autonomous_task_run
thing has the sync_compatible
decorator on it which doesn't know both that this is an async context and that this task is sync - have a fix coming here
The goal here is for each subscriber to be able to filter to a subset of the tasks they are interested in (i.e. which tasks a task server is serving). This required routing task runs into queues and monitoring multiple queues for tasks. This was a good opportunity to refactor some of the mechanics here to capture the idea that a `TaskQueue` is really two queues (a "regular" queue and a high-priority retry queue). This led me down a path of tidying up the implementation to remove globals and encapsulate more of the behavior.
ff23c80
to
9c43e26
Compare
The goal here is for each subscriber to be able to filter to a subset of the
tasks they are interested in (i.e. which tasks a task server is serving). This
required routing task runs into queues and monitoring multiple queues for
tasks. This was a good opportunity to refactor some of the mechanics here to
capture the idea that a
TaskQueue
is really two queues (a "regular" queue anda high-priority retry queue). This led me down a path of tidying up the
implementation to remove globals and encapsulate more of the behavior.