DBアクセス成功時に再接続試行回数をリセット

SolidCableはデータベースからメッセージを取得できた際に reconnect_attempt を 0 にリセットし、不要な再接続判定を防止します。

背景

reconnect_attempt が成功した再接続後にリセットされないため、同一プロセス内で再接続回数が蓄積されたままになるという問題がありました（#81）。

reconnect_attempt は接続エラーが発生したときにインクリメントされ、reconnect_attempts で上限が制御されます。エラーが解消されてもカウントが残ると、以降のループで再接続が不要にも関わらず上限に達したと判定される可能性があります。

この状態は、正常に DB へアクセスできたにも関わらず再接続ロジックが誤作動するリスクを孕んでいるため、成功時にカウントをリセットする必要がありました。

技術的な変更

broadcast_messages メソッド内に self.reconnect_attempt = 0 を追加し、メッセージを正常にブロードキャストした直後にカウントをリセットするようにしました。

@@
-                 broadcast(message.channel, message.payload) if should_broadcast_message
+                 broadcast(message.channel, message.payload) if should_broadcast_message
+                 self.reconnect_attempt = 0
                  self.last_id = message.id

この一行の追加により、broadcast_messages が正常に処理を完了したタイミングで reconnect_attempt が 0 に戻り、以降の接続判定で正しい再接続回数が評価されます。既存のロジックや設定値には変更が加えられていません。

設計判断

reconnect_attempt のリセットを broadcast_messages 内で行う選択は、成功判定が確実に得られるポイントに処理を集中させるという設計意図に基づきます。

この変更は新たなフラグや外部メソッドを導入せず、単一の代入文で実装されているため、既存コードへの侵入度が極めて低く、後方互換性を損なうリスクがありません。

結果として、再接続上限ロジックはそのまま維持されつつ、正常な DB アクセス後にカウントがクリアされることで、再接続判定が本来の意図通りに機能します。

まとめ

この PR は broadcast_messages が成功した直後に reconnect_attempt をリセットすることで、不要な再接続判定を防ぎ、SolidCable の接続管理を正確に保ちます。変更は一行の代入で完結しており、既存の動作に影響を与えません。