PR #122 で Slack::PostRepository に webhook 応答の検査と再送を入れた結果、Discord::PostRepository とほぼ同じロジックが二箇所になった。
重複しているのは次の 3 つ。
MAX_SEND_ATTEMPTS / MAX_RETRY_WAIT の定数- 429 と 5xx を
Retry-After に従って再送し、それ以外は例外にする送信ループ
Retry-After を読んで待機上限で丸める retry_after
PR #122 では共通化を見送った。
再送は HTTP の話なので、送信先を抽象化する Notify::PostRepository に置くと、送信先に依存しないはずの notify 層が HTTP を知ることになる。
かといって新しい抽象を足すと、issue #120 の対応の範囲を超える。
考えられる置き場所は、たとえば「webhook URL に JSON を POST して再送する」クライアントを一段設け、Slack / Discord のリポジトリがそれを使う形。
どちらのアダプタも HTTP::Client を持ち、@uri.request_target に JSON を POST しているだけなので、素直に切り出せるはず。
急ぐ話ではない。
どちらのアダプタも動作しており、重複が壊れるとしたら片方だけ直したときなので、次にこのあたりを触るときに合わせて整理したい。
PR #122 で
Slack::PostRepositoryに webhook 応答の検査と再送を入れた結果、Discord::PostRepositoryとほぼ同じロジックが二箇所になった。重複しているのは次の 3 つ。
MAX_SEND_ATTEMPTS/MAX_RETRY_WAITの定数Retry-Afterに従って再送し、それ以外は例外にする送信ループRetry-Afterを読んで待機上限で丸めるretry_afterPR #122 では共通化を見送った。
再送は HTTP の話なので、送信先を抽象化する
Notify::PostRepositoryに置くと、送信先に依存しないはずの notify 層が HTTP を知ることになる。かといって新しい抽象を足すと、issue #120 の対応の範囲を超える。
考えられる置き場所は、たとえば「webhook URL に JSON を POST して再送する」クライアントを一段設け、Slack / Discord のリポジトリがそれを使う形。
どちらのアダプタも
HTTP::Clientを持ち、@uri.request_targetに JSON を POST しているだけなので、素直に切り出せるはず。急ぐ話ではない。
どちらのアダプタも動作しており、重複が壊れるとしたら片方だけ直したときなので、次にこのあたりを触るときに合わせて整理したい。