Rails 7.1 has a new default that runs after_commit callbacks in the order they are defined.
new_framework_defaults_7_1.rb:
# Run `after_commit` and `after_*_commit` callbacks in the order they are defined in a model.
# This matches the behaviour of all other callbacks.
# In previous versions of Rails, they ran in the inverse order.
#++
Rails.application.config.active_record.run_after_transaction_callbacks_in_order_defined = true
This causes previously stored files not to be removed when they are updated, because after_commit :"remove_previously_stored_#{column}", on: :update runs after after_commit :"reset_previous_changes_for_#{column}" (which resets the @removed_uploaders).
As a workaround, the above configuration can be set to false, but it would be nice if carrierwave could handle this. Probably it's enough to check the configuration and define the callbacks the other way around.
Rails 7.1 has a new default that runs after_commit callbacks in the order they are defined.
new_framework_defaults_7_1.rb:
This causes previously stored files not to be removed when they are updated, because
after_commit :"remove_previously_stored_#{column}", on: :update
runs afterafter_commit :"reset_previous_changes_for_#{column}"
(which resets the@removed_uploaders
).As a workaround, the above configuration can be set to
false
, but it would be nice if carrierwave could handle this. Probably it's enough to check the configuration and define the callbacks the other way around.