弊ぼっちは現在、
Pumaは
MAX_THREADS=6
WEB_CONCURRENCY=1
Sidekiqは
SIDEKIQ_THREADS=5
になってる。スレッド数をそれぞれ1減らしてからojとSidekiqを更新してみゆ。
まず
$ heroku config:set MAX_THREADS=5 SIDEKIQ_THREADS=4
ojを更新してもトゥート受け取ってるじゃないのよもー
よーしお父さんsidekiqも上げちゃうぞー
配達できない問題のスタックトレースを記録できた!! やったあ!!! ActivityPub::DeliveryWorkerが例外を上げるとその後なんもできなくなるみたいです。なるほどなるほど。
https://gist.github.com/zunda/9623ec92de7c40a046afafa58633cc43
とりあえずslugをrollbackしておきました。
というわけでruby-3.1.2のMastodonでsidekiqを上げるとキューをさばかなくなる問題の再現にはタイムアウトするリモートも必要みたい。めんどーw とりあえず明日は例外をちゃんと読む。
nilになっている@callbackはlib/sidekiq/processor.rbで定義されていてProcessor.newに&blockで渡されているはず。Processor.newがあるのはlib/sidekiq/manager.rb。2ヶ所あって両方とも、Processor.new(@config, &method(:processor_result))と呼んでいる。第2引数の取り扱いがRubyのバージョンで違うのかな？テスト用のmainのMastodonでエラーの再現とRubyのバージョンの変更を試してみるね。
【悲報】Herokuアプリはweb dynoを起動しておかないでも503を返すのでトゥートを配達しようとしてもタイムアウトの例外が上がりませんw
app/lib/request.rbで必ず例外を上げるようにしたんだけどnomethoderrorにはたどりつかないな…
もしかしたら以前のsidekiqでキューしたタスクを再実行する必要があるのかな…
似たスタックトレースのIssueを眺めてみると、Sidekiq::Processor.newにblockを渡してないところがあるはずとのこと。そうよねえ…
https://github.com/mperham/sidekiq/issues/5375#issuecomment-1150388000
ってscout_apmなるほど!! これはテストの子では有効化してないぞ
https://github.com/mperham/sidekiq/issues/5375#issuecomment-1150612934
scout_apm-4.1.2/lib/scout_apm/background_job_integrations/sidekiq.rbのdef intall_processorあたりが問題っぽい。これじゃイニシャライザにblockを渡してないよね。
::Sidekiq::Processor.class_eval do
def initialize_with_scout(*args)
agent = ::ScoutApm::Agent.instance
agent.start
initialize_without_scout(*args)
end
alias_method :initialize_without_scout, :initialize
alias_method :initialize, :initialize_with_scout
end
scout_apmを新しくすればなおる気がする!!
https://github.com/scoutapp/scout_apm_ruby/issues/449
なおった