お腹空いたな

エラートラッキングツール使ってみた - HackMD https://hackmd.io/@pZLFDeR0S0yMK8zjUj3pgA/ry-fMtCM8

BugSnagとSentry以外にもいくつか選択肢はあったんだなぁ。今error trackingをどうこうする気はないからメモだけ。

BugSnagの記事割と少なくて自分が困ったのと、Connect RPCのリクエストパラメータを取れるように自分でしたのに忘れてたので、主に未来の自分の為にメモ。

func NewInterceptor() connect.UnaryInterceptorFunc {
	interceptor := func(next connect.UnaryFunc) connect.UnaryFunc {
		return connect.UnaryFunc(func(ctx context.Context, req connect.AnyRequest) (connect.AnyResponse, error) {
			res, err := next(ctx, req)
			var connectErr *connect.Error
			if err != nil && !errors.As(err, &connectErr) {
				errInErr := bugsnag.Notify(err, ctx, func(event *bugsnag.Event) {
					event.GroupingHash = fmt.Sprintf("%s - %s", event.Context, err)
					event.MetaData.AddStruct("request body", req.Any())
				})
				if errInErr != nil {
					return nil, fmt.Errorf("fail to bugsnag.Notify() in connect interceptor: %w: original error is %w", errInErr, err)
				}
			}
			return res, err
		})
	}
	return connect.UnaryInterceptorFunc(interceptor)
}

にはConnect RPCのAPIのpath(ex: /foo.v1.Bar/BazRpc)が入ってるので、これとエラー文字列をグルーピングのキーにしている。
これやっておかないと、Golangだと殆どのエラーが*errors.errorStringで一緒くたにグルーピングされてしまう。

リクエストパラメーターはevent.MetaData.AddStruct("request body", req.Any())で雑に放り込んでおけば、EXTRA DATAとして確認できる。

Connect RPCのinterceptorとして作ってて、こいつが取れるのはUnaryだけでStreaming RPCでのエラーは取れない。
BugSnagのダッシュボードで見られるStacktraceでは、このinterceptorでエラーが発生した事になってしまい実際のhandlerでのエラー発生行は分からないので、event.Contextとエラー文字列から
なんとか特定する必要がある。

あっつあっつ

お腹空いたが食べ物が無い

そういえば1回位は食べてみようで、サムライマックの炙り醤油風 トリプル肉厚ビーフを食べてみた。
まぁうまいはうまい。パティとチーズとソースが混ざった味の中で、パティが3枚だと肉感が増えて少しパンチ力を増してる気はしないでもない。
ただこれに限らずだけど、やっぱマクドナルドはコスパ悪い感じあるなぁ。同じ金額感でどっかで定食食べた方が満足度は高そう。
めちゃくちゃ久しぶりだし、たまにはまぁいいかの気持ち。

ジブリってサブスクにないんか。レンタルDVDあるならサブスクにも提供して欲しい。もうDVD再生できる機器が無いし・・

【Jalapeco steak Shinjuku main store】 / Tokyo Shinjuku ward｜TENPOSSTAR https://www.tenposstar.com/enu/merchant/64e58c9bd59f0
ハラペコステーキがハラペーニョのJalapになってて草

んーゼリーでも食べるか

お腹減ってないけどなんか食べたい

【新人プログラマ応援】開発タスクをアサインされたらどういう手順で進めるべきか #Ruby - Qiita https://qiita.com/jnchito/items/017487cd882091494298

いつか取り出してSlackとかに貼りたい時が来るかもしれないのでメモ

MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub https://developers.freee.co.jp/entry/large-in-clouse-length-cause-full-scan
MySQLでIn句に大量の要素を渡すとまずい理由 https://zenn.dev/nasu/articles/410bdb9739cd35

WHERE INで万の要素を渡すって、どういう状況なんだろ？特殊なバッチ処理とか？

あとzennの記事がwhere number inって書いてるけど、restraurantsテーブルにnumberは書いてないからidだろうか？