-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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 keyword arguments warnings in Active Job #38260
Conversation
Related rails#38053, rails#38187, rails#38105. This is a reattempt to fix keyword arguments warnings in Active Job. Now Ruby (master) has `Hash.ruby2_keywords_hash{?,}` and that will be backported to 2.7.1. ruby/ruby#2818 https://bugs.ruby-lang.org/issues/16486 I've emulated that for 2.7.0 and older versions.
@@ -170,7 +170,7 @@ class ClassArgument; end | |||
end | |||
|
|||
test "allows for keyword arguments" do | |||
KwargsJob.perform_later(argument: 2) | |||
KwargsJob.perform_now(argument: 2) |
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 change is to excercise perform_now
with keyword arguments, perform_later
is already tested by MultipleKwargsJob
.
rails/activejob/test/cases/test_helper_test.rb
Lines 561 to 570 in d72f940
def test_assert_enqueued_with_selective_args | |
args = ->(job_args) do | |
assert_equal 1, job_args.first[:argument1] | |
assert job_args.first[:argument2].key?(:b) | |
end | |
assert_enqueued_with(job: MultipleKwargsJob, args: args) do | |
MultipleKwargsJob.perform_later(argument2: { b: 2, a: 1 }, argument1: 1) | |
end | |
end |
Fix keyword arguments warnings in Active Job
You should have wait the review of this PR before merging. This is increasing the storage on the background job database because of a warning on Ruby. I don't think it is a good solution. Can we revert it? |
This PR also don't address the problem that will be caused when we have to really split keyword arguments and regular arguments. When the split happen the |
result = serialize_hash(argument) | ||
result[SYMBOL_KEYS_KEY] = symbol_keys | ||
result[RUBY2_KEYWORDS_KEY] = true if Hash.ruby2_keywords_hash?(argument) |
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 mean storing 25 characters, ~96 more bytes to the database just to get rid of a warning on Ruby. I don't think this is a good trade off.
@@ -161,7 +162,8 @@ def delivery_job_class | |||
|
|||
def arguments_for(delivery_job, delivery_method) | |||
if delivery_job <= MailDeliveryJob | |||
[@mailer_class.name, @action.to_s, delivery_method.to_s, params: @params, args: @args] | |||
ruby2_keywords_arguments \ | |||
@mailer_class.name, @action.to_s, delivery_method.to_s, params: @params, args: @args |
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 is still not future safe. Workers with old code will still break as soon we change the code to actually split the arguments. We should at least add a kwargs argument to the job with a default as nil
right now so, when we have to split the arguments for real, the workers are ready to receive a pass them. But I'm not sure if we can even pass them right now, what makes this solution still not good enough.
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'm not sure why "Workers with old code will still break as soon we change the code to actually split the arguments", but I agree that "We should at least add a kwargs argument to the job with a default" as a future plan, that is to be required if Ruby team will decide to remove internal kwargs flag (my hope that removal should not be happen since there is a serialization/deserialization problem, though).
Anyway, I'll revert this for now.
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 say we deploy Rails X to production, the first request running on 6.1 add a job to the queue with the arguments and keyword arguments split. The job worker that fetches that job is still using Rails X-1, given the deploy is still happening. That same worker would have code that doesn't know how to deal with the split keyword arguments so it would only pass around the regular arguments and leave the keyword arguments out of the method call.
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.
Thanks for the explanation. I see that concern is almost not for this change but for a future plan.
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.
Right. As soon we release the code to deal with this is better. It means that the entire 6.1+ releases will be able to run Ruby 3.0 without having to release a version to prepare and a version to actually add support.
Related rails#38053, rails#38187, rails#38105, rails#38260. This is a reattempt to fix keyword arguments warnings in Active Job. Now Ruby (master) has `Hash.ruby2_keywords_hash{?,}` and that will be backported to 2.7.1. ruby/ruby#2818 https://bugs.ruby-lang.org/issues/16486 I've emulated that for 2.7.0 and older versions.
Related #38053, #38187, #38105.
This is a reattempt to fix keyword arguments warnings in Active Job.
Now Ruby (master) has
Hash.ruby2_keywords_hash{?,}
and that will bebackported to 2.7.1.
ruby/ruby#2818
https://bugs.ruby-lang.org/issues/16486
I've emulated that for 2.7.0 and older versions.