feat: syntax-check JavaScript code fields after find/replace patches (v2.72.0)

[czlonkowski]

Summary

Implements the expansion proposed by @NextLevelManagementAdvisors in #1012: after a find/replace patch lands on a JavaScript code field, the engine now parses the result and fails the operation if the patch left the code syntactically broken — instead of saving corrupted code to the workflow (live, if the workflow is active).

How it works

• After patchNodeField (and the legacy __patch_find_replace path in updateNode) applies its patches to a field whose last path segment is jsCode or functionCode, the final value is parsed via the AsyncFunction constructor — parse-only, the code is never executed.
• The async-function wrapping matches how n8n itself wraps Code-node JavaScript, so top-level return and await parse fine.
• On a SyntaxError, the operation throws with the parser's message before any mutation lands on the node (patchNodeField validates before setNestedProperty; __patch_find_replace validates before the draft swap), preserving atomicity.
• Regression-only: the guard blocks only breakage the patch itself introduces. A field that was already unparseable before patching stays patchable, so pre-existing corruption (e.g. saved by the pre-2.71.1 $ bug) can be repaired incrementally instead of being blamed on the patch.
• Bounded and fail-open: code over 1MB is not parsed (the synchronous parse would otherwise be an event-loop DoS lever), and any non-SyntaxError parse failure (CSP EvalError, RangeError from pathological nesting) lets the patch through — the guard is a best-effort seatbelt, and it steps aside whenever it cannot judge. If it ever rejects newer syntax that the n8n runtime's V8 accepts, the tool docs point to updateNode full-field set as the unguarded escape hatch.

Scope decisions

• Per-operation check on the final value: intermediate invalid states within one operation's patches array are fine; the error message tells agents to combine dependent edits into a single operation.
• Skipped: values starting with = (n8n expressions embed {{ }}, not plain JS), pythonCode, non-code fields, and non-SyntaxError constructor failures (e.g. environments where Function construction is blocked) — the guard never blocks what it cannot check.
• Direct updateNode sets of jsCode are intentionally out of scope: there the agent supplies the whole value deliberately; the corruption risk this guards against is specific to find/replace splicing.

Testing

• 17 new unit tests across the review rounds: corruption rejected with clear message and workflow unchanged (jsCode and parameters.functionCode), already-broken field still patchable on both paths, genuine broken-to-fixed repair, expression-prefix stripping still guarded, top-level return/await accepted, multi-patch operation with invalid intermediate state accepted, regex-mode results guarded, =-expressions/pythonCode/non-code fields skipped, checked code never executed (sentinel), 1MB ceiling and RangeError nesting fail open, and continueOnError lets later operations proceed after a guard rejection.
• Full diff-engine suites pass (355 tests across the two files) and the full unit suite is green; typecheck and build clean. Live-verified by the MCP tester agent: 7 scenarios plus an expression-exemption check against a real n8n instance, all passing.

Version

• 2.72.0 (minor — new validation behavior), changelog entry added, runtime version synced.

Conceived by Romuald Członkowski - www.aiadvisors.pl/en

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds a safety guard to the workflow diff engine so that find/replace-style patches against JavaScript code fields (e.g. Code node jsCode, legacy functionCode) are syntax-checked before being committed, preventing silent corruption of live workflows during partial updates.

Changes:

• Parse patched jsCode / functionCode values via an async-function constructor and reject patches that introduce SyntaxError before mutating workflow state.
• Add unit tests covering syntax-guard behavior for patchNodeField and the legacy __patch_find_replace update path.
• Bump version to 2.72.0 and document the new behavior in tool docs and the changelog.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/unit/services/workflow-diff-engine.test.ts	Adds unit coverage for rejecting syntactically broken patched JS code and ensuring atomicity (no mutation on failure).
src/services/workflow-diff-engine.ts	Introduces getJsSyntaxError() and integrates it into patchNodeField and __patch_find_replace application flow.
src/mcp/tool-docs/workflow_management/n8n-update-partial-workflow.ts	Documents the new syntax-checking behavior for patch operations on JS code fields.
package.runtime.json	Bumps runtime package version to 2.72.0.
package.json	Bumps main package version to 2.72.0.
package-lock.json	Syncs lockfile version fields to 2.72.0.
CHANGELOG.md	Adds a 2.72.0 entry describing the new syntax-check guard.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Test Results Summary

📊 Artifacts

• 📄 Test Results
• 📊 Coverage Report
• ⚡ Benchmark Results

---

Generated at Tue, 18 Aug 2026 22:04:25 GMT
Commit: 18201d0
Run: #1498

[Copilot]

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

tests/unit/services/workflow-diff-engine.test.ts:1441

• This test claims the workflow is unchanged on failure, but applyDiff() always clones the input workflow, so checking the original workflow object doesn't validate atomicity of the failed patch against the returned workflow state. Using continueOnError lets you assert result.workflow remained unchanged while still expecting success=false.

      expect(codeNode?.parameters.jsCode).toBe('const x = 2;');
    });

    describe('JavaScript syntax guard on code fields', () => {
      const codeWorkflow = (jsCode: string) => {
        const workflow = JSON.parse(JSON.stringify(baseWorkflow));

tests/unit/services/workflow-diff-engine.test.ts:662

• These assertions check that the input workflow object wasn't mutated, but applyDiff() always deep-clones the workflow at the start. That makes this test redundant/misleading for verifying that a failed __patch_find_replace doesn't partially update the returned workflow. Consider running this in continueOnError mode so you can assert against result.workflow while still expecting success=false.

This issue also appears on line 1436 of the same file.

      const codeNode = result.workflow!.nodes.find((n: any) => n.name === 'Code');
      expect(codeNode?.parameters.jsCode).toBe('const x = (;\nreturn x + 1;');
    });

    it('should reject __patch_find_replace patches that leave jsCode with a syntax error', async () => {

[Copilot]

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/services/workflow-diff-engine.ts:230

• The error message says "The workflow was not modified.", but in continueOnError mode later operations can still modify the workflow, making this statement misleading. Consider wording it as "No changes were applied for this operation" (or similar) so it's always accurate.

  if (!syntaxError) return;
  // An "=" original is an expression — unchecked but not broken JS. Only a
  // plain-JS original that itself fails to parse opens the repair gate, so
  // patching an expression into broken plain JS is still caught.
  if (!original.startsWith('=') && jsSyntaxErrorOf(original) !== undefined) return;

[Copilot]

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/services/workflow-diff-engine.ts:209

• jsSyntaxErrorOf() currently returns undefined both when code is syntactically valid and when the guard could not check (size > MAX_SYNTAX_CHECKED_LENGTH or a non-SyntaxError like EvalError/RangeError). In assertPatchedJsSyntax(), that makes an uncheckable original look “valid”, so a patch that leaves a SyntaxError can be rejected even though the guard explicitly intends to fail-open whenever it cannot judge (and should not treat unknown-original as a confirmed regression).

type JsSyntaxCheck =
  | { status: 'valid' }
  | { status: 'invalid'; message: string }
  // Could not judge the code either way: oversized, or the parser gave up
  // with a non-SyntaxError (a CSP EvalError, a RangeError from pathological

[Copilot]

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/services/workflow-diff-engine.ts:1169

• The error message for invalid JS syntax uses the hard-coded operation label passed here. Using "__patch_find_replace" can be confusing for callers who invoked an updateNode operation (the outer error wrapper will become Failed to apply operation: __patch_find_replace: ...). Consider labeling it as updateNode + the patch mode so the message matches the user-facing operation.

        assertPatchedJsSyntax('__patch_find_replace', path, current, original);

src/mcp/tool-docs/workflow_management/n8n-update-partial-workflow.ts:466

• This doc string says the syntax guard applies only to parameters.jsCode / parameters.functionCode, but the implementation checks the last path segment (jsCode or functionCode) regardless of prefix. To avoid surprising users (e.g. nested paths ending in .jsCode), update the wording to match the actual behavior.

      'Patches to parameters.jsCode or parameters.functionCode are parsed as JavaScript after applying: a patch that breaks previously-valid code fails the operation. Only the final result of one operation\'s patches array is checked, so apply dependent edits in a single operation. A leading = is stripped before parsing, matching how n8n runs these noDataExpression fields. Fields that were already invalid before patching and pythonCode are not checked; code over 1MB is never parsed, and patching valid code into something unverifiable is rejected — set the full value via updateNode (unchecked) if that is intended. The parse runs on the MCP server\'s Node.js: in the rare case it rejects newer syntax your n8n runtime accepts, set the full field value via updateNode instead (not guarded)',

[codecov]

Codecov Report

❌ Patch coverage is 95.00000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/services/workflow-diff-engine.ts	94.87%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!