Skip to content

fix: use keyword arguments when calling refresh draft job #3778

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

Merged
merged 2 commits into from
Jun 3, 2025

Conversation

lovrocolic
Copy link
Collaborator

@lovrocolic lovrocolic commented Jun 3, 2025

Context

It seems that AR deserialisation in jobs does not work sometimes in combination with uniqueness constraint

Description

After investigation, seems that preferred approach is switching to keyword arguments which are handled a bit different during deserialisation

@lovrocolic lovrocolic requested a review from ancorcruz June 3, 2025 14:23
Copy link
Contributor

@ancorcruz ancorcruz left a comment

Choose a reason for hiding this comment

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

LGTM!

@lovrocolic lovrocolic merged commit 3fc5362 into main Jun 3, 2025
14 checks passed
@lovrocolic lovrocolic deleted the fix-refresh-draft-params branch June 3, 2025 14:36
@@ -12,7 +12,7 @@ class RefreshDraftJob < ApplicationJob

unique :until_executed, on_conflict: :log, lock_ttl: 12.hours

def perform(invoice)
def perform(invoice:)
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't there a risk of introducing a minor breaking change (during the deployment) with this change ? If clock gets deployed before worker and the job runs, it would serialize the argument as keyword args and the running worker code would still expect a global id. This could lead to some dead jobs until worker finish deploying.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I would say it should be fine. Even if we end up with some dead jobs (which is low probability), this job is safe to run multiple times and we can re-run it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants