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