インターネットが壊れた

fastly使ってるとこが全滅した感

死んだのはfastlyか．CDNの死亡じゃないか

ほんとだよ，いつまでも仕事なんかしてんじゃないよというgithubからのメッセージ

githubが応答返さない

あーこのfinってLBが送ってくるやつじゃん．つまりLB側のタイムアウトなわけか

timeoutを指定しないと，結局だれかがfinを送るぞ？誰じゃ？これのタイムアウトさえ短くできればいいんだが

client側のtimeoutを指定しない場合どうなるんだろう，という観測

そもそもうちのLBが悪いのはわかったんだけど，それにしてもnet/http側もちょっと中途半端なのではないか……

本気を出せば初回接続時のエラーハンドリングでRequestCanceledを拾ってCloseIdleConnectionsすれば，transportが保持しているidleConnを吹き飛ばしてリトライ可能ではある．けど，ちょっと場当たり的すぎてあんまりやりたくないんだよなぁ．やるのであれば，そもそもclient-goがRESTClient生成するときに，正しくリトライできるclientを生成してほしい

memberが死んだときにresetを送ってくれるLBと送ってくれないLBがある．どういうことだよｗｗｗ

ずっとupdateしてていつになっても終わらん……

珍しくproposalを書く

あちぃね

わろたｗｗｗ

はらへ

落としたインスタンスをLBがmemberから外してくれないし，維持したtcp connに対してもackを返し続けているのでkeepaliveし続けてしまう．せめてmemberから外してほしいし，なんならそのタイミングでresetを送ってほしい

idleConnが全然クリアされない．これほぼほぼLBのせいだと思うんだけど，どうしたもんか……