Skip to content
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

feat(task-processor): Add priority support #2847

Merged
merged 16 commits into from
Oct 31, 2023
Merged

Conversation

gagantrivedi
Copy link
Member

@gagantrivedi gagantrivedi commented Oct 13, 2023

Thanks for submitting a PR! Please check the boxes below:

  • I have run pre-commit to check linting
  • I have filled in the "Changes" section below?
  • I have filled in the "How did you test this code" section below?
  • I have used a Conventional Commit title for this Pull Request

Changes

In order to allow high priority tasks to be executed first, this PR adds a priority column to the task table(with default null)

How did you test this code?

Update unit test

@vercel
Copy link

vercel bot commented Oct 13, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 24, 2023 10:28am
flagsmith-frontend-preview ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 24, 2023 10:28am
flagsmith-frontend-staging ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 24, 2023 10:28am

@github-actions github-actions bot added the api Issue related to the REST API label Oct 13, 2023
@gagantrivedi gagantrivedi marked this pull request as draft October 13, 2023 05:53
@github-actions
Copy link
Contributor

github-actions bot commented Oct 13, 2023

Uffizzi Preview deployment-38400 was deleted.

@codecov-commenter
Copy link

codecov-commenter commented Oct 13, 2023

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (4f7464b) 95.59% compared to head (f951507) 95.64%.
Report is 23 commits behind head on main.

❗ Current head f951507 differs from pull request most recent head 5887a05. Consider uploading reports for the commit 5887a05 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2847      +/-   ##
==========================================
+ Coverage   95.59%   95.64%   +0.04%     
==========================================
  Files        1009     1011       +2     
  Lines       28833    28979     +146     
==========================================
+ Hits        27562    27716     +154     
+ Misses       1271     1263       -8     
Files Coverage Δ
api/audit/tasks.py 94.44% <100.00%> (+0.10%) ⬆️
api/core/migration_helpers.py 94.87% <100.00%> (+0.75%) ⬆️
api/edge_api/identities/edge_request_forwarder.py 100.00% <100.00%> (ø)
api/edge_api/identities/tasks.py 97.77% <100.00%> (+0.05%) ⬆️
api/environments/tasks.py 100.00% <100.00%> (ø)
api/task_processor/decorators.py 100.00% <100.00%> (+11.59%) ⬆️
...igrations/0008_add_get_task_to_process_function.py 100.00% <ø> (ø)
...pi/task_processor/migrations/0010_task_priority.py 100.00% <100.00%> (ø)
...tions/0011_add_priority_to_get_tasks_to_process.py 100.00% <100.00%> (ø)
api/task_processor/models.py 95.61% <100.00%> (+0.20%) ⬆️
... and 4 more

... and 15 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -90,12 +101,14 @@ class Meta:
def create(
cls,
task_identifier: str,
priority: TaskPriority = TaskPriority.NORMAL,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matthewelwell think we can get rid of schedule_task and just use this method directly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can, but I quite like having the helper method to differentiate them. What's the benefit in removing it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the name is slightly odd, no? I'd expect it to schedule the task(i.e: put on some queue?) but it only creates the class instance. Does that make sense?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, you mean that it doesn't actually persist it to the DB? But that's the same as the create method too, right? We could update the name to create_scheduled_task ? Maybe you're right though that we should consolidate the 2 methods.

Copy link
Member Author

@gagantrivedi gagantrivedi Oct 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean that it doesn't actually persist it to the DB?

Yes, exactly

Copy link
Member Author

@gagantrivedi gagantrivedi Oct 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed schedule_task method, but now I am not sure if it looks any better 😕 ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, there's less code so that's always a good thing. I think I would prefer to keep the logic regarding the queue in the Task model though. Can we just handle that in the create method now instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, done

@gagantrivedi gagantrivedi marked this pull request as draft October 16, 2023 06:20
@gagantrivedi gagantrivedi marked this pull request as ready for review October 16, 2023 08:29
Copy link
Contributor

@matthewelwell matthewelwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a couple of minor comments.

This certainly seems like a ok approach but did we consider any other approaches here? For example, having distinct queues and the ability to define workers for those queues directly?

I guess we could still define a number of workers that operate only on a given priority if we wanted to, right?

@@ -71,7 +72,7 @@ def call_environment_webhook_for_feature_state_change(
call_environment_webhooks(environment, data, event_type=event_type)


@register_task_handler()
@register_task_handler(priority=TaskPriority.HIGHEST)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be highest? I think we basically want to reserve highest for those tasks involved in creating the environment document, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think this is as import as environment document, right? We want the identity overrides to reflect as soon as possible

Copy link
Contributor

@matthewelwell matthewelwell Oct 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it's slightly lower priority than environment document changes.

@@ -90,12 +101,14 @@ class Meta:
def create(
cls,
task_identifier: str,
priority: TaskPriority = TaskPriority.NORMAL,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can, but I quite like having the helper method to differentiate them. What's the benefit in removing it?

with open(file_path) as f:
return cls(f.read(), reverse_sql=reverse_sql)
def from_sql_file(
cls, file_path: str, reverse_sql: str = None, reverse_sql_file_path: str = None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably add validation here to ensure that reverse_sql and reverse_sql_file_path aren't used together? I guess an alternative would be to use a single argument and try to infer if it's a file path (e.g. os.file.exists()).

@@ -90,12 +101,14 @@ class Meta:
def create(
cls,
task_identifier: str,
priority: TaskPriority = TaskPriority.NORMAL,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, there's less code so that's always a good thing. I think I would prefer to keep the logic regarding the queue in the Task model though. Can we just handle that in the create method now instead?

Copy link
Contributor

@matthewelwell matthewelwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a few minor comments but this looks good. It relies on us clearing down the taskprocessor_task table before we can release though.

Comment on lines 111 to 112
if queue_size:
if cls.is_queue_full(task_identifier, queue_size):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick:

Suggested change
if queue_size:
if cls.is_queue_full(task_identifier, queue_size):
if queue_size and cls.is_queue_full(task_identifier, queue_size):

task_identifier=task_identifier,
args=args,
kwargs=kwargs,
def is_queue_full(cls, task_identifier: str, queue_size: int) -> bool:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can probably be marked as private now, right?

Suggested change
def is_queue_full(cls, task_identifier: str, queue_size: int) -> bool:
def _is_queue_full(cls, task_identifier: str, queue_size: int) -> bool:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Issue related to the REST API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants