n8n は成功しているのに出力がない
execution は緑、所要時間は短く、件数は 0。本当に処理対象がなかった、という場合もあります。成功の表示が付いた障害、という場合もあります。見分けるための材料は、その workflow 自身の履歴です。
n8n ではこう見えます
実行を開くと node はすべて緑ですが、最後の node のデータ欄に item がありません。書き込みも送信も行われておらず、n8n はそれで満足しています。
- 普段は数十件動いている workflow が、成功かつ 0 件になっている。
- いつもよりはるかに速く終わっている。
- 最後の node が、結果を書き込む node ではなく filter や IF になっている。
- ある日から 0 件の実行が続いている。
よくある原因
出力ゼロは、エラーの形ではなくデータの形で現れます。だから何も例外を投げません。
filter の条件が当たらなくなった
上流でフィールド名が変わった、ステータスの値が変わった、日付の書式が変わった。条件式は正しいまま、何にも一致しなくなります。
クエリや API が空のリストを返している
パラメータの変更、ページングのリセット、ビューの削除、権限の絞り込み。どれもエラーを出さずに、満杯の結果を空に変えます。
credential の期限切れや権限の縮小
権限不足のリクエストに 401 ではなく空のコレクションを返す API があります。node は中身のないまま成功します。
上流のスキーマ変更
存在しなくなったフィールドを読む式は空を返します。実行は続き、空欄を書くか何も書かずに、成功します。
重複除去がすべてに一致するようになった
「新規のみ」の判定が誤ったキーで比較していると、すべての item が既知として落ちます。
timezone のずれた日付範囲
「前日」の範囲を誤った timezone で作ると、レコードが 1 件もない期間を見に行くことがあります。
いまの n8n で確認する方法
目的は、「空で正常」と「空で異常」をプラットフォーム側が区別できる形にすることです。
件数の推移を比べる
その workflow の直近数週間の実行を見ます。0 件が 3 日から出始めたなら、3 日に何かが変わっています。
node ごとにデータを見る
最初の node から順に追い、件数が 0 になる node を特定します。その node か、その 1 つ前が原因です。
件数を見る IF を置く
取得の直後に件数を判定し、0 件の経路を目に見えるところへ流します。そのまま後続へ吸い込ませないでください。
空の経路に Stop and Error node を置く
その workflow にとって 0 件が失敗なら、n8n にそう言わせます。投げられたエラーは Error Workflow で通知できますが、成功はできません。
普段の値を書き留める
その workflow の普段の件数と所要時間を記録します。その数字がないと、execution の一覧を見た人には 0 が異常だと分かりません。
OutcomeGuard はどう検出するか
覚えておかなければならない数字を、OutcomeGuard が先に持っています。
- workflow ごとの普段の件数と、空の結果が本当に普通である頻度を学習し、履歴と矛盾する 0 件のときだけ EMPTY_OUTPUT を出します。
- 0 件まで落ちない件数の崩れは VOLUME_ANOMALY で出します。半分しか入っていない取り込みは、誰も気づかない種類の障害です。
- 所要時間も見ます。普段の 10 分の 1 で終わった実行は、たいてい何も運んでいません。
- Outcome Contract で「期限までに N 件以上」と決めれば、「空は疑わしい」を「空は失敗」に変えられます。
- 空が普通の workflow には何も言わず、履歴が足りない workflow は異常ではなくデータ不足として報告します。