n8n 1.123.70 - Expression Isolate Poll Fix

n8n published [email protected] on 12 August 2026 as a stable patch, not a prerelease. The change that matters for operators is a race in the VM expression engine: a scheduled poll tick could release the isolate that workflow activation still owned, which then failed later expression evaluation and left the workflow in a retry loop.

The full release notes and downloads are on the GitHub release page.

n8n evaluates expressions inside an isolate when N8N_EXPRESSION_ENGINE is set to vm. The isolate is a borrowed bridge from a pool. acquireIsolate is idempotent per caller. releaseIsolate always returns the bridge to the pool. There is no reference count.

That contract breaks when two events overlap. Workflow activation holds the isolate while it tests poll nodes. A poll tick registered with the cron scheduler can fire in that window for a node that is already active. The tick calls acquire, which does nothing because activation already holds the bridge, then still releases in its finally block. Activation continues. Later work such as trigger counting tries to evaluate a webhook path expression and the runtime throws IsolateError: No bridge acquired for this context. Call acquire() first. The workflow then sits in an activation retry loop.

The blast radius is that one workflow, not the whole process. The trigger is the 1.x line with the VM engine, two or more poll nodes, and a webhook whose path is an expression. A slow test poll makes the race easy to hit: the second node’s test is still running when the first node’s minute cron fires.

Issue 35934 and commit ae489a6 change the acquire contract. ExpressionEvaluator.acquire now returns a boolean: true when a bridge was newly taken, false when the caller already held one. packages/core/src/execution-engine/active-workflows.ts stores that result in ownsIsolate and only calls releaseIsolate when the tick owns the bridge. The initial test poll still skips acquire and release. The same guard landed in withExpressionIsolate in packages/cli/src/utils.ts.

Unit tests cover three cases: no isolate traffic on the test poll, acquire and release on a scheduled tick that owns the bridge, and no release when acquire reports the isolate was already held. Operators who saw endless activation retries on poll heavy 1.x workflows should treat this tag as the fix, not as a config change.

The rest of the tag is dependency pinning. Three of the four remaining notes are pnpm overrides edited in root package.json and pnpm-lock.yaml.

adm-zip moves from 0.5.10 to 0.6.0 in commit c4d602e. tar moves from 7.5.16 to 7.5.21 in commit d97e715. undici moves from 7.28.0 to 7.29.0 by rewriting the override key from undici@<=7.28.0 to undici@<=7.29.0 in commit ab2a6bf.

These are the zip, tar, and Node HTTP client libraries forced through the root overrides map so every workspace package sees the same floor. The release notes do not name a CVE. Treat the bumps as version floors, not as a documented exploit writeup. The diff against [email protected] is on the compare page.

A fourth pin sits under the core heading. fast-uri moves from 3.1.2 to 3.1.5 in commit 8e4e278 by adding "fast-uri": "3.1.5" to the same overrides map. The notes give versions only.

No migration steps appear in the notes. This is a patch on the 1.123 line. If you run that line with polling triggers and the VM expression engine, take [email protected]. If you do not use that engine or have no poll nodes, the isolate race does not apply; the override bumps still ride along.