なんもしてないけど直った．本当になんもしてない

接続切れたときの挙動が怪しいの，VPNが原因な気がしてならない

klogをio.MultiWriterでファイルとstdoutに書き出してファイルを生成しようと思ったけど，fileってdeferでcloseされるんで，その前に使うのあんまりよくないかなぁ．というか欲しい情報得るためにはラッパーを作ったほうがいいのでは……

あれ？俺何もしてないけど勝手に治ってない？

久しぶりにetcdのローリングアップデート問題をやるか

ゾンビランドサガで宮野真守がアプリボワゼしとるｗｗｗ

github issueのtemplateを更新するときに，そのtemplateを利用して起票されたopenなissueの一覧を得ることはできないだろうか．issueを作った後にtemplateを更新すると，既にあるissueを更新すべきかどうか判断する必要があるんだが，そもそもどのissueがこのtemplateで作られたかわからんので，それを判断することすらできない

あるある．でもスタートアップだと結構分析基盤とかにあいのりしがち……そして運用メンバーは分析基盤に直アクセスするspreadsheetを作っていたりするのだ……

githubのschedule reminderがすべての未レビューを通知してくれてない気がする．notificationから見ると見落としがいくつかある

レビューがいっぱい溜まっている

これぞ禁則事項

あーこれはロジックが難しい．作戦考えないと実装できん

いるの！？

あとノーコードのサービス自体の開発すげーめんどくさい気がしてならない

わかる

というわけでとりあえず保存するところまではできた

あーあたりだ．確かにtimelineのパラメータとしてはnotificationsしか受け取ってないわ．
https://git.pleroma.social/pleroma/pleroma/-/blob/v2.3.0/lib/pleroma/marker.ex#L17

pleromaってhomeのmarker保存されないのかな

一杯の概念よ

家の中が暑い

ほげー

外暑いね

これはdbが重くなりすぎるな……

あー失敗したかも．これはデータ構造がよくない

こりゃーチョロくなかった．かなり面倒だな……

ECRからのimage pullにはprivate link使いたいなぁ

コードのレビューは，実は普段そんなに突っ込む気はなくて，スタイルとかあまり気にしない（というかそんなのlinterに任せるので俺が突っ込みたくない）んだけど，proposalとかになると無限に議論可能でレビューがいつになっても終わらない．方針とか設計になると，想定されるケースをいくらでも思い浮かべられるので，みんな自分が困りそうなところをどんどんコメントしてくる．

どーんときた

ゆれゆれ

一ヶ月調べ続けて結局直すところは2行．そんなもんだよね

あーいけたぞ．ResponseHeaderTimeoutを入れた状態でForceAttemptHTTP2をfalseにすると，timeout awaiting response headerの後にidleConnがクリアされる．
さて，なんでhttp2だとクリアされないんだよ

ResponseHeaderTimeoutが一番怪しいと思ったんだけど，このときでもidleConnを開放してくれないのかね……

この告知動画が最高点にならないことを祈る…… / 他30件のコメント https://t.co/w7ptwYPrE8 “Netflixの実写版「カウボーイビバップ」今秋配信　音楽は菅野よう子 - ITmedia NEWS” (82 users) https://t.co/hs7vJdbfiF

今日のレビューは重い……

インターネットが壊れた

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のせいだと思うんだけど，どうしたもんか……

やはり自前でCloseIdleConnectionsを呼ぶと解決する．つまりnet/http側のエラーハンドリングに問題がある気がしてならない．でも標準ライブラリのデバッグはやったことないな……

おや，healthmonitorのhelath check間隔が長いな……

timeoutが発生したときに任意の処理を差し込む方法はないかな……

となるとこれリクエストをキャンセルしている，タイムアウトを発生させているのはどこなんだ

本来deadlineがきたらDeadlineExceededなerrorになるはずなのに，それが発生しないのも謎い．これ，この上にconnection poolを作ってるからなんだろうな．どちらかというとこれはidle timeoutに利用されている気がする

net.Connのdeadlineってconn自体のdeadlineなのか．ReadDeadlineとか説明と違うのでは？

jokerさんがCTO交代しとる……！お疲れさまでした / 他3件のコメント https://t.co/umZpLjaWnx “Reproの三代目CTOとして尾藤正人氏が参画 | Repro - カスタマーエンゲージメントプラットフォーム” (8 users) https://t.co/g1QGsnsQ8S

午前中にレビューが全部終わるの久しぶりだな

めっちゃ眠い