Skip to main content

Slack / Discord 通知

学習は長いので、ずっと Studio を見続ける人はいません。終端の onCompletedonFailed コールバックは、チームが普段いる場所にステータスメッセージを流すのにうってつけです。 このレシピは Slack incoming Webhook を使います。Discord、Microsoft Teams、任意の HTTP エンドポイントも同じやり方で動きます。fetch できるものなら何でも通知先になります。

パターン

<!here> メンションは失敗時にしか発火しないので、成功時は誰も呼び出しません。チームの学習ジョブが実際にどれだけ失敗するかに合わせて緊急度を調整してください。

なぜ内側の try / catch が大事か

Webhook リクエストが throw すると(Slack 障害、DNS の不調、コードが 200 番台以外を再 throw するなど)、コールバックは reject します。コールバックからの未捕捉の throw は、そのエラーで trainer.wait() を即座に reject させます(SDK § ライフサイクルコールバック)。これは SSE 再接続ループには送られず、maxReconnectAttempts の下でリトライされることもありません。つまり onCompleted から発火した不安定な Webhook が wait() 全体を中断させてしまい、それを待っている CI や cron のオーケストレーターは、本来は成功した学習を失敗として扱ってしまいます。 Webhook は学習成功の判定基準ではなく副作用として扱ってください。内側で catch し、必要に応じてログに残します。

バリエーション

ステップごとの進捗 ping。 onLog と組み合わせて N ステップごとに 1 行投稿:
うるさいので、重要な学習だけにしたいなら process.env.NOTIFY_PROGRESS === "1" でゲートしてください。 学習中のサンプル共有。 学習中の評価レシピ と組み合わせる: 各チェックポイントのサンプルをレビューチャネルに投稿し、学習が続いている間にチームメンバーがリアクションで反応できます。
他の宛先。 PostHog の capture()、Datadog のイベント、DB への insert: パターンは同じです。副作用をエラーを飲み込む async ヘルパーの内部に閉じ込め、ライフサイクルコールバックから呼び出します。トレーナーファイルに追加のオーケストレーションは不要です。

心に留めておくこと

  • 内側の try / catch は必須。 通知はあれば便利ですが、Webhook の障害が、本来は成功した学習の wait() を中断させるのは望ましくありません。
  • シークレットをトレーナーファイルに置かない。 例では SLACK_WEBHOOK_URLprocess.env から読み、Webhook が git に入らないようにしています。トークンベースの宛先全般に同じ考え方を適用してください。
  • errorstring であることを忘れない。 onFailederror 引数はバックエンドが送った文字列で(SDK § ライフサイクルコールバック)、Error インスタンスではありません。そのまま埋め込んでください。.message を参照しないでください。