dyno cycleに対するsocket.ioの対処って典型的なものがないのかな。
@anqou 一般論になっちゃいますけどアプリ側はSIGTERMをもらってから、現在進行中のリクエストに答えて接続を切って止まるまで30秒の猶予があります https://devcenter.heroku.com/articles/error-codes#r12-exit-timeout クライアント側は接続を切られちゃったらしばらく待ってつなぎ直すしかなさそうですー。
devcenter.heroku.comHeroku Error Codes | Heroku Dev CenterA description of the custom error information written to logs when your app experiences an error.
@zundan なるほど……となると、クライアントごとにIDをふったうえで、再接続してきたときにIDをもとに判別できるように、データベースで管理する感じになるんですかね。
@anqou あまり詳しくなくて申し訳ないのですが、そんな感じだと思います。たぶん、まずブラウザから接続しにいったときにクッキーでトークンを持たせて、それをWebSocketでつなぎにいくときにクッキーとかクエリストリングで渡す感じなのかな、と想像してます。Mastodonだと/ap1/v1/streaming/?stream=user&access_token=…につなぎに行って感じなので。トークンの管理はデータベースでもRedisみたいなのでも良さそう。
@zundan やっぱりそうなりますよね……。やってみます。ありがとうございます。