いくつかのコールバックの落とし穴（そしてRails 5の修正）

Railsはafter_saveを呼び出します レコードが保存された直後のコールバック。 ただし、そのレコードは、データベースがトランザクションするまで、Sidekiqが使用しているような他のデータベース接続では表示できません。 コミットされますが、これは少し後で発生します。 これは、Sidekiqが質問を保存した後、コミットする前に、質問を見つけようとする可能性があることを意味します。記録が見つからず、爆発します。

この問題は非常に一般的であるため、Sidekiqにはそれに関するFAQエントリがあります。そして、簡単な修正があります。

after_saveの代わりに ：

class Question < ActiveRecord::Base
  after_save :index_for_search

  # ...
end

after_commitを使用する ：

class Question < ActiveRecord::Base
  after_commit :index_for_search

  # ...
end

そして、Sidekiqがあなたのモデルを見ることができるまで、あなたの仕事はキューに入れられません。

したがって、バックグラウンドジョブをキューに入れたり、行った変更について別のプロセスに通知したりする場合は、after_commitを使用してください。 。そうしないと、触れたばかりのレコードが見つからない可能性があります。

しかし、もう1つ問題があります…

OK、after_saveの束を切り替えました after_commitを使用するためのフック 代わりは。すべてがうまくいくようです。すべてをチェックインして家に帰る時間ですよね？

まず、テストを実行する必要があります：

require 'test_helper'

class QuestionTest < ActiveSupport::TestCase
  test "A saved question is queued for indexing" do
    assert_enqueued_with(job: QuestionIndexerJob) do
      Question.create(title: "Is it legal to kill a zombie?")
    end
  end
end

  1) Failure:
QuestionTest#test_A_saved_question_is_queued_for_indexing [/Users/jweiss/Source/testapps/after_commit/test/models/question_test.rb:7]:
No enqueued job found with {:job=>QuestionIndexerJob}

おっと！テストはジョブをキューに入れるべきではありませんか？ そこで何が起こったのですか？

デフォルトでは、Railsは各テストケースを独自のデータベーストランザクションでラップします。これは本当に物事をスピードアップすることができます。テスト中に行ったすべての変更を元に戻すには、1つのデータベースコマンドだけで済みます。

ただし、これはafter_commitも意味します コールバックは実行されません。 after_commitのため コールバックは、最も外側の場合にのみ実行されます トランザクションがコミットされました。

saveを呼び出すとき テストケース内では、（多かれ少なかれ）トランザクションをコミットしますが、それは2番目に外側です。 今トランザクション。つまり、after_commit コールバックは、期待どおりに実行されません。そして、それらの内部で何が起こっているかをテストすることはできません。

この問題も簡単に修正できます。 test_after_commitを含めます Gemfile内のgem：

group :test do
  gem "test_after_commit"
end

そしてあなたのafter_commit フックは最後から2番目の後に実行されます トランザクションがコミットされます。 これがあなたが期待していたことです。

「それは変だ。 Railsに付属するコールバックをテストするために、まったく別のgemを使用する必要があるのはなぜですか？自動的に発生するのではないでしょうか？」

あなたが正しい。それは変だね。しかし、それは長い間奇妙なままではありません。

Rails 5が出荷されたら、test_after_commitについて心配する必要はありません。 。この問題は約1か月前にRailsで修正されたためです。

私自身のコードでは、after_commitを使用しています 多くの。私はおそらくafter_saveを使用するよりも多く使用しています ！しかし、問題と奇妙なエッジケースがないわけではありません。

バージョンごとですが、改善されています。 また、after_commitを使用する場合 適切な場所では、多くの奇妙でランダムな例外が発生しなくなります。