after_commit all the things

[andrek-data-axle]

Problem

after_save and its friends may be called even after the transaction encapsulating the database operation is rolled back.
Still working on fixing the unit test.

Solution

Use after_commit

Notes

Do not use after_create_commit etc because https://www.kostolansky.sk/posts/unexpected-after-commit-behaviour/

Links

https://api.rubyonrails.org/v6.0.6.1/classes/ActiveRecord/Transactions/ClassMethods.html#method-i-after_commit
https://jakeyesbeck.com/page10/#aftercommit
https://blog1.westagilelabs.com/when-to-use-after-commit-in-rails-f5e53a22bb9

[j1wilmot]

Yes, makes sense to use after_commit when trying to sync multiple systems. I'm curious what performance impact of this could be.

[betesh-at-data-axle]

elastic_record only supports Ruby 2.7+:

elastic_record/elastic_record.gemspec

Line 9 in 3a2de44

s.required_ruby_version = '>= 2.7'

Based on https://www.fastruby.io/blog/ruby/rails/versions/compatibility-table.html, that pretty much limits it to Rail >= 6.

So if the point of this line is to ensure that we're using a version of Rails that supports after_commit (which has been around since Rails 3), we can remove it.

Otherwise, this is the same as if defined?(ActiveRecord::Base) && base < ActiveRecord::Base, which I think is a more explicit way of expressing what we're trying to achieve here.