Do not evaluate :if arguments when :on is not satisfied for transaction callbacks

[Erol]

Summary

This addresses #28019 by prepending the :on action check before the supplied :if argument. The previous behavior appended :on at the end of the list when setting up a callback, allowing :if conditions to be evaluated even if the :on transaction scope is not satisfied.

class Topic < ActiveRecord::Base
  after_commit :do_something, on: [:create, :update], if: :check_something?
end

topic = Topic.create #=> Calls :check_something?
topic.save #=> Calls :check_something?
topic.destroy #=> No longer calls :check_something?

[rails-bot]

r? @rafaelfranca

(@rails-bot has picked a reviewer for you, use r? to override)

[Erol]

Hi @rafaelfranca, is there anything I can do to move this forward?

[rafaelfranca]

Hmm, this one is tricky. I'm sure there are people expecting the if to evaluate before the on condition. I think this changes make sense, but I want to hear @matthewd and @jeremy opinions.

[niborg]

@rafaelfranca surely people shouldn't be putting any model-changing logic in the :if statements? It should only be used to evaluate a boolean expression, so as I understand it nothing would change for those who might expect the 'if' before the 'on'. But for those who expect the 'on' before the 'if', unnecessarily evaluating the 'if' statement could raise an error. (In my case, the 'if' was being unnecessarily evaluated on destroy, when it was specified for an 'on: :update', and during the destroy lifecycle an association that would otherwise be present was not.)

[matthewd]

Yeah, I think this should be relatively safe: the if condition can't force the overall condition to true when the on doesn't match. Concur with @niborg that anyone mutating the model inside the if deserves what they get.

IOW, it is a behavioural change, but not one that seems likely to affect applications using the API in good faith.

[rafaelfranca]

Seems good. It also matches the validation behavior.