I sell a small pack of n8n workflows built around one idea: automation should ship with its own acceptance tests, and sends should stay disabled until those tests pass. Before listing it, I did the only honest thing you can do with a claim like that — I ran my own tests against my own product on a live n8n instance. They failed. Twice. This is the story, because both bugs are ones your workflows probably have too.
Bug 1: require('crypto') doesn't exist where you think it does
My intake workflow deduplicates submissions with a hash key. Locally-authored, looked clean, "obviously worked." On a stock n8n install it died instantly:
Module 'crypto' is disallowed
n8n's Code node sandboxes away Node builtins by default. If your dedupe, signing, or ID logic uses require('crypto'), it works on your tweaked dev instance and breaks on your client's stock one. Fix: a pure-JS hash (I used double FNV-1a — dedupe keys don't need cryptographic strength) or enabling builtin access consciously via env config — as a documented decision, not an accident.
Bug 2: your env-var read is a silent crash on stock installs
Every "armed/disarmed" gate in the pack reads an env var: delivery stays OFF until AF_DELIVERY_URL exists. Except on default installs, N8N_BLOCK_ENV_ACCESS_IN_NODE makes $env access THROW — so my fail-safe gate was actually a fail-crash gate. The fix is boring and important:
let url = '';
try { url = $env.AF_DELIVERY_URL || ''; } catch (e) { url = ''; }
Fail-safe now means: on any stock install, the workflow imports, runs, and refuses to send — instead of erroring out and teaching the buyer your stuff is broken.
Why this is a sales pitch (honestly)
Both bugs share a shape: they're invisible until the workflow runs somewhere you didn't build it. A demo can't catch them. A screenshot can't catch them. Only acceptance tests executed on a clean instance can — which is why every workflow I ship has its criteria written on the canvas in a sticky note, and a checklist the buyer runs before trusting anything.
The tests cost me an evening and two embarrassing bugs. They also mean the thing I sell is the thing I verified — and that discipline is the actual product.
(The full acceptance-first pack is at https://niekonieczny.gumroad.com/l/imbsml — and the error handler alone at https://niekonieczny.gumroad.com/l/uwxmpx.)
Top comments (2)
Acceptance tests are underrated because they protect the promise, not just the implementation. Catching two real bugs before customers saw them is exactly the kind of feedback loop that justifies writing them early.
'Protect the promise, not just the implementation' is a better one-line summary than anything in my article. That was exactly the shape of my second bug: every implementation-level check was green, but the promise — 'this gate fails safe' — was broken on any stock install. Since then I write the criteria as promises the buyer could read aloud, and only then translate them into checks. Thanks for this, Alex.