Rails ActiveRecord CALLBACKS constant processing: HOW?

jgomo3 · August 12, 2022, 5:29pm

Trying to find the source code of “after_commit” and “after_rollback” transactional callbacks, I stumbled upon this CALLBACKS constant definition inside the ActiveRecord::Callbacks module. It is an array with this form:

[
      :after_initialize, :after_find, :after_touch, :before_validation, :after_validation,
      :before_save, :around_save, :after_save, :before_create, :around_create,
      :after_create, :before_update, :around_update, :after_update,
      :before_destroy, :around_destroy, :after_destroy, :after_commit, :after_rollback
]

What I don’t get is what line of code in the whole Rails project process that array.

What in the end will loop over that array?

And, how can I make sense of what after_commit and after_rollback do?

I’m wondering this last one because I’m supporting an old 4.2 Rails app, which according a warning: those callbacks currently ignore errors but will not in the future. So planing on upgrading, I want to prepare my code to or manage the possible errors or behave explicitly the same as now (Ignoring the errors) when I do upgrade to a newer Rails.

AndyMaleh · August 14, 2022, 1:11pm

Usually callbacks are run with meta-programming using run_callbacks, so you generally shouldn’t see direct references to after_commit, yet just :commit like run_callbacks(:commit) {...} OR run_callbacks :commit do ... end:

github.com

rails/rails/blob/08af60e01dcf33db34a5ecafab8be25e373f7bfb/activesupport/lib/active_support/callbacks.rb#L95


      
          #   end
          #
          #--
          #
          # As this method is used in many places, and often wraps large portions of
          # user code, it has an additional design goal of minimizing its impact on
          # the visible call stack. An exception from inside a :before or :after
          # callback can be as noisy as it likes -- but when control has passed
          # smoothly through and into the supplied block, we want as little evidence
          # as possible that we were here.
          def run_callbacks(kind)
            callbacks = __callbacks[kind.to_sym]
          
          
  if callbacks.empty?
              yield if block_given?
            else
              env = Filters::Environment.new(self, false, nil)
              next_sequence = callbacks.compile
          
          
    # Common case: no 'around' callbacks defined
              if next_sequence.final?

So, look for that instead. Check out the line that runs it in rails/activerecord/lib/active_record/transactions.rb here (for whatever reason, they are using a different more specialized version of run_callbacks that is _run_commit_callbacks):

github.com

rails/rails/blob/08af60e01dcf33db34a5ecafab8be25e373f7bfb/activerecord/lib/active_record/transactions.rb#L323


      
          end
          
          
# Call the #after_commit callbacks.
          #
          # Ensure that it is not called if the object was never persisted (failed create),
          # but call it after the commit of a destroyed object.
          def committed!(should_run_callbacks: true) # :nodoc:
            @_start_transaction_state = nil
            if should_run_callbacks
              @_committed_already_called = true
              _run_commit_callbacks
            end
          ensure
            @_committed_already_called = @_trigger_update_callback = @_trigger_destroy_callback = false
          end
          
          
# Call the #after_rollback callbacks. The +force_restore_state+ argument indicates if the record
          # state should be rolled back to the beginning or just to the last savepoint.
          def rolledback!(force_restore_state: false, should_run_callbacks: true) # :nodoc:
            if should_run_callbacks
              _run_rollback_callbacks

By the way, it seems that ActiveRecord::Callbacks::CALLBACKS is only used for testing in activerecord/test/cases/callbacks_test.rb

Anyways, I did not do exhaustive research, yet just a quick look. I hope that was helpful to continue further.