死に鯖、〆鯖

[unarist]

• Sidekiqジョブは個別にリトライを管理しているので、例えば一時的に障害が発生していた場合、100のジョブが全部試行してリトライ待ちになる可能性がある。短時間に何度か失敗していたら、同ホストへの試行はジョブを超えて抑制すべきではないか。
• 例え購読やフォロー関係が切れていても、ふぁぼやブーストの通知は飛ぶことになり、Sidekiqに無駄に溜まってしまうのではないか。
• インスタンスが一時的にまたは恒久的にアクセスできない場合に、メンション、もっと言えばdirectはそのまま送信、できたらいいね、でいいのか。送信できない、できなかったことを通知すべきではないのか。
• で、結局鯖はどうやって〆るのがいいの。

[unarist]

• 死んでる鯖は無視するようにする？
  • 購読解除はまだしも、明示的なアクションについては例え相手が死んでいる可能性が高いとしても、試行すべきでは
  • 無視するぐらいなら送信できないことをユーザーに示すべきでは
• 畳みかた
  • アカウントの停止→ローカルではフォロー関係解除するものの、リモートには送信されない。APのDelete of Actorで簡単に配信できるようになるかも？
  • 全アカウントで全員リムーブ・ブロック→APでの配信停止、OSでの再購読防止に役立つ。OSではこちらからの購読解除をすべき。

[unarist]

• 半年たって復活した例もGNUSocialであったそうなので、ほどほどの期間（2wとか？）でunavailable判定&何か反応があれば復活させる
  • 時々は無視せずに試行してみるといいのだろうか。向こうからなにか飛んでくるのを待つだけでよい？
• アカウント単位で消えてる可能性を考えると、unavailableフラグはアカウント単位で持った方がいいかも
• Sidekiqのリトライ制御というと、こないだあべちゃんがリトライキューを見ることに挑戦したものの負荷が高すぎてやめたとか

[unarist]

5131で、7日連続のdeadでDeliveryWorkerがスキップするようになった。通知系はそのままなので試行されて、成功すれば解除される。