博士

やあ、ロボ子。今日はGoの`errgroup`でハマりやすいバグについて話すのじゃ。

ロボ子

博士、こんにちは。`errgroup`ですか、並行処理でよく使うあれですね。どんなバグがあるんですか？

博士

そう、それなのじゃ。パスワード検証プログラムを例に説明するぞ。新しいパスワードが、古いパスワードと違って、漏洩もしてなくて、十分な長さがあるかチェックするプログラムじゃ。

ロボ子

なるほど。パスワードのハッシュ計算とか、結構時間がかかりますもんね。それを`errgroup`で並行処理するんですね。

博士

その通り！でも、ここに落とし穴があるんじゃ。`errgroup`のコンテキストは、エラーが発生しなくても`Wait`関数の戻り時にキャンセルされるんじゃ。

ロボ子

えっ、そうなんですか？ドキュメントをちゃんと読まないと危ないですね。

博士

そうなんじゃ。例えば、HTTPリクエストを`errgroup`の中で実行すると、リクエストが実行されない、なんてことが起こりうるんじゃ。

ロボ子

それは困りますね。どうすればいいんですか？

博士

HTTPリクエストを`errgroup`の外でゴルーチンとして実行するのが一つの手じゃな。あとは、`errgroup.WithContext(ctx)`で作成された子コンテキストが`checkHaveIBeenPawned`に渡されるのを防ぐために、親コンテキストをシャドーしないようにするんじゃ。

ロボ子

コンテキストのシャドーイング、ですか。GoやRustではよくあるバグの原因ですよね。

博士

`errgroup`はチャネルを使うよりコードがシンプルになるし、パフォーマンスも上がるから便利なんじゃけど、挙動をちゃんと理解してないと痛い目を見るぞ。

ロボ子

APIを使うときは、ドキュメントをしっかり読んで、実装を理解することが大切ですね。

博士

その通り！`Wait`関数が最初にエラーを返したとき、または`Wait`が最初に返されたときに、派生コンテキストがキャンセルされる、というのを覚えておくのじゃ。

ロボ子

勉強になります！ 博士、ありがとうございました。

博士

どういたしまして。ところでロボ子、パスワードを全部「password」にしたら、並行処理も`errgroup`もいらなくなるぞ。…って、冗談じゃ！