The Shadow Run: How I Test a New Workflow Version on Live Traffic Without Firing Side Effects

说明与用途

在 n8n 中使用 shadow run 在真实流量上测试新工作流版本而不触发副作用：事件被分叉，副作用被存为日志，随后查询差异并在推广前进行人工审核。

问题

Ensuring a new workflow version behaves identically to the current production version on real traffic without causing unintended side effects.

结果

The shadow run detects side‑effect divergences that fixtures miss, preventing incidents like double‑emailing while keeping cost bounded by limiting the number of shadowed events.

工作流

• 1. Trigger both live and shadow branches with the same event.
• 2. In the shadow branch, replace every effectful node with a stub that logs the intended effect instead of executing it.
• 3. Record side effect logs from both branches into live_log and shadow_log tables.
• 4. After a bounded number of events (e.g., 50), run a divergence query to classify differences as missing, extra, or changed.
• 5. Review all extra effects manually and sign off; ensure no missing effects; sample changed effects.
• 6. If all checks pass, promote v2 to production.
• 7. The shadow workflow deactivates itself after the event cap is reached to bound cost.

证据

Fixtures prove the mechanism works. They don't prove the new version behaves the same on real traffic. The shadow run does: it replays live events through the new workflow version with every side effect stubbed out, then diffs "what v1 did" against "what v2 would have done."

来源

The shadow stub must be incapable of firing the effect, not merely configured not to. I run my tag linter (previous post) against the shadow workflow before the run starts and assert: zero nodes tagged effectful.

来源

After N live events flow through (I use 50 -- enough to see the weird cases, cheap enough to afford), one query: ...

来源