Open endangurura opened 1 year ago
Can validate that this is happening on my application:
Rails 6.0.6.1 Ruby 3.0.6 (formerly 2.7.7) AASM 5.5.0
request.accept! # => ArgumentError: wrong number of arguments (given 1, expected 0)
request.accept # => succeeds
I'm guessing the problem is somewhere between
124: safely_define_method klass, "#{name}!", ->(*args, &block) do
125: aasm(aasm_name).current_event = :"#{name}!"
126: aasm_fire_event(aasm_name, event, {:persist => true}, *args, &block)
127: end
and
121: # Returns true if event was fired successfully and transaction completed.
122: def aasm_fire_event(state_machine_name, name, options, *args, &block)
123: return super unless aasm_supports_transactions? && options[:persist]
This is made complicated by the changes in args around ruby 3. In the lower code (ruby 3.2 in my case), args is an array with one hash in it. That's probably not what's wanted. Getting that to work for ruby 2.x and 3.x may involve something like
args_hash = Array(args).first
Ah - it looks like maybe this is fixed in https://github.com/aasm/aasm/tree/add_ruby_3.2_in_github_workflows
Looks like that was only a partial fix.
@kwerle is there a PR for that? I feel the proposed solution is a bit hacky, and also resolves the problem where it blows, not where it originates. The better solution would be to separate the keyword arguments in the Invoker
, and add Ruby 3.2 support there.
I found that location by stepping into my code where it was failing. I certainly didn't dig into the AASM code to figure out the right fix. It seems likely that my research could be useful for writing a failing test if nothing else. This issue will block my company from doing a ruby upgrade - which is not a priority for us this quarter. It will become a priority in a couple of months. I'm kind of hoping that it'll be fixed and pushed by then :-)
@kwerle we're in the same situation, and we might be taking a stab at it soon.
@kwerle the fix you mentioned is present on 5.5.0. Also, aasm is currently running with ruby 3.0 and rails 6.1 (not 6.0 yet). This example seems to implement the situations that both you and @that-jill discussed, and it seems to pass under all conditions. Can you create a failing spec?
Can you create a failing spec?
I'm on an M1 mac and do all my dev work in docker containers. I have not been able to get the aasm test environment up and running so I don't believe I will be able to write a good test. If nobody else tackles this before we really need it, I'll provide a monkey patch that addresses the issue - probably later this quarter.
I forgot to link the example I believe represents your problem now, and is passing on main.
Do you agree that it's the same case? If you don't, we could work together to get a failing spec and I can take care of fixing it.
I'm starting to dig into this, and the first broken spot I see is we have:
event :submit do
before { |some_variable:| self.foo = some_variable }
transitions from: ...
success :...
end
my_object.submit(some_variable: 1234)
It looks like in ruby 3.2 and aasm 5.5.0 before
is no longer being called with the some_variable: hash parameter.
Ah - instead it is being passes as a hash: {:some_variable =>1234}
For those following with interest - I think I've given enough detail to formulate a reasonable test in https://github.com/aasm/aasm/issues/834#issuecomment-1793154832 . I will not be pursuing this further - our workaround is to simply accept the hash and use that.
We have the same problem here. Has anyone found a way to fix it?
@fbraure the current workaround is to simply accept the argument as a hash and fetch options from it, as pointed by @kwerle
I'm working on upgrading an application from Rails 5.2 to latest. Currently running:
rails 6.1 ruby 3.0 aasm 5.5 (I tried 5.4 too, same results)
When I try to call events with bangs, I get an ArgumentError
wrong number of arguments (given 1, expected 0)
call
With Ruby 2.7 the ArgumentError is not raised