Backportの適用

[da-yoshi-k]

Rails7.1がリリースされるまでのバックポートとして、以下のGemの導入を検討する。 直近ではAction Cableが利用不可となっているケースは少ないため、Fly.ioのQAの更新なども確認する。 https://github.com/anycable/action-cable-redis-backport

[da-yoshi-k]

• 下記PRにて導入済み。数日様子見を行う予定。 https://github.com/da-yoshi-k/huddle-guide-backend/pull/39

[da-yoshi-k]

2/18には事象が再現していたため、connectionの問題を疑っています。 検証のため、connectionファイル内のcurrent_userによる同定の記述をコメントアウトしました。

• 以下PRを参照 https://github.com/da-yoshi-k/huddle-guide-backend/pull/40

[da-yoshi-k]

アプリが動作しなくなるパターンとして、ワーク画面で1時間以上動作がなく開いたままにしていることが関係している気がしています。（Upstash Redisのタイムアウト時間と関連させて考えると）

そのため、ワークに45分までといった制限を設けて、1時間以上放置されている場合をなくすための処理を追加することを検討します。 (#91 参照)

[da-yoshi-k]

意図的にcableを破棄した場合にも挙動に変化がなかった。 ※1時間でタイムアウトし、それ以降に接続しようとした時にワークショップが開始できないような事象が発生する。

以下のコメントを参考にfly.io内にUpstash Redisではない、別アプリケーションとしてRedisサーバを立てるものとする。 https://community.fly.io/t/upstash-redis-connection-lost-econnreset-redis-connectionerror/8182/18

[da-yoshi-k]

Redis用のアプリケーションをFly.ioに立て接続を試したところ、時間が経ってから再接続した時に動作しないということは無くなった。 ただし、WindowsのChromeではよくコネクションの切断が発生し、操作できないタイミングが多くあった。

[da-yoshi-k]

• フロント側で、接続していないタイミングでは接続中のモーダルを表示するような修正を実施。以下でユーザーが復帰可能かつ操作できないタイミングでは操作を中断するという制御を行いました。（ただし、ユーザー体験とのトレードオフであるため、別途改善を検討すること。） https://github.com/da-yoshi-k/huddle-guide-frontend/pull/129