I am working on updating an app to use the new Rails 7.1 default
run_after_transaction_callbacks_in_order_defined = true.
Prior to Rails 7.1,
after_commit callbacks ran in reverse order they were defined.
However, you could add
prepend: true to a later after_commit callback, to get it to be added to the beginning of the list… where it would run last. This certainly is confusing, we can see why it was changed.
But just note: you could use
prepend: true to alter the chain insertion point of an
after_commit callback, the same as you can for most (all?) other lifecycle
After Rails 7.1, with
run_after_transaction_callbacks_in_order_defined = true,
after_commit callbacks are… run in the order they are defined.
But it seems we can no longer use
prepend: true to alter the insertion order of an
after_commit call back.
# Rails 7.1 with run_after_transaction_callbacks_in_order_defined = true after_commit :one after_commit :two # one will run first, then two #vs: after_commit :one after_commit :two, prepend: true # NO CHANGE, one will run first, then two
Is this intentional? A bug? Just how it is?
When updating my app to use the new default order, there are times – just as there were before – when I want to use
prepend: true to change a callback’s insertion order.
One of my use-cases has to do with
after_commit set in a subclass and superclass (with STI)… so there is no good way to change the order in source code, I think.
But there is no longer any way to do that, which is causing me pain in my migration to the new default. It surprises me that
prepend: true option was intentionally taken away, when other
after_ callbacks still have it?
Can anyone find any reasonable workaround? I don’t think there is one?