Mastodonのdefaultキューの処理が追いつかないと、ストリーミングで古い投稿が流れてくるようになります。
LTLが2時間遅れている場合、FTLは4時間、HTLは6時間程度の遅れになる傾向があります。
これは、defaultキューで順番に処理されるWorkerを、それぞれ1回、2回、3回通過しなければいけないからです。
連合は、リモートから受け取った投稿などをActivityPub::ProcessingWorkerというWorkerが処理したあとで、DistributionWorkerというWorkerが配送します。
ローカルは、所属サーバのユーザーの投稿があると、ActivityPub::ProcessingWorkerを経由せずに直接データベースに内容を反映した後、DistributionWorkerによってサーバ内の各タイムラインに配送処理が行われます。
ホームは、DistributionWorkerの中からさらにユーザー毎にFeedInsertWorkerが走ります。
連合の中のローカルの投稿は、ローカルと同じ遅延になります。
なお、初回ロード、リロードした場合、データベースから直接タイムラインの情報を取得します。
そのため、ストリーミングを経由せずに内容が構築されます。
LTLは、ユーザーが投稿を行って受理された直後にデータベースに反映されるため、ここでは遅延が発生しません。
連合は、ローカルユーザーは遅延なし、リモートユーザーはWorker1回分の遅延となります。
ホームは、FeedInsertWorkerによって内容が構築されるため、ストリーミングと同様にWorker3回分の遅延となります。
ちなみに、ストリーミングの処理自体は、redisというオンメモリのデータベースを経由して、node.jsによるストリーミング専用のプロセスが行っています。
このプロセスが止まったり異常が発生した場合は、タイムライン上部に「‥‥‥‥‥‥」というマーカーが出て、新しいストリーミング（リアルタイムのタイムライン更新情報）を受け取れていないことが明示されます。
このマーカーをクリックすると再接続を試みますので、一時的な問題の場合は解決します。サーバ側が落ちているときはダメです。
便宜上、ストリーミングが遅延していると表現してしまいますが、ストリーミングサーバが原因であるのではなく、単に配送しろという指令がredisに届いてないだけだったりします。
『sidekiqのdefaultキューの遅延が原因でストリーミングが遅延している』ということになります。
最後にひとつ付け加えておきますが、この仕組み上、リロードしまくればローカルの遅延を回避できるということになりますが、サーバに多大な負荷が掛かるため、全体としては症状が悪化します。
遅延している場合は、管理者に不具合状況の連絡を行った上で、回復まで、あまり負荷をかけないように見守ってあげてください。
