Order dependency of filters depending on other filters about active_interaction HOT 1 CLOSED

This turns out to be an interesting issue. Prior to 4.0.0 we would populate the object with the raw value provided in the input and then override them with the filtered value. I think we did it that way at the time to preserve the raw values for use in errors but I don't exactly remember. The result of this is that in some cases what you noticed would work. The raw value given was available and used in the provided default proc and functioned correctly. This however, was luck.

Here's an example (using 3.8.3):

class Test < ActiveInteraction::Base
  integer :a, default: -> { b + 1 }
  integer :b

  def execute
    a
  end
end

> Test.run!(b: 2) # => 3
> Test.run!(b: '2') # => TypeError (no implicit conversion of Integer into String)

This happens because the b value was not converted into an integer so when we try to add 1 to it we get an error. If you flip the order of :a and :b it does work.

The real error here is that we wrote improper values in the first place. In a way this error was accidentally fixed in 4.0.0.

I'm sorry it caused confusion. That's certainly frustrating. I've thought about ways to help this and the best I can think of is to process the inputs first by filters without default procs, then any inputs passed, and finally filters that received no input and have a default proc. The issue is that we still have the same issue with any of those final filters with no inputs and default procs. We've shrunk the chances of it happening but it's much more confusing for someone to reason about and much more prone to failing in a surprising way. I think having them work in order is probably the best bet.

from active_interaction.