Validate versioned workflows against their own node schemas

[justadityaraj]

Context

Notion 3 made the database-page title field required. Workflows saved with Notion 2.2 were still being validated against that latest schema, so a valid nested title expression produced Required property 'Title' cannot be empty.

Review also exposed a related path: persisted *Tool variants resolve version rows through their base node, whose historical schema does not contain the generated toolDescription property.

Fixes #1037

Changes

• resolve versioned node properties from the workflow node's typeVersion
• preserve the generated toolDescription property when a Tool variant uses its base node's historical schema
• fall back to the latest schema when an exact version row is unavailable
• cover the Notion 2.2, Google Calendar Tool 1.3 strict-profile, and missing-version paths

User impact

Older versioned nodes are validated against the schema they actually execute with, including stored Tool variants, while current nodes retain their existing validation.

Verification

• Tool-variant regression test failed before the fix with Property 'toolDescription' won't be used - not visible with current settings
• Local validator/repository suite: 374 tests passed
• Local npm run typecheck, npm run build, and git diff upstream/main...HEAD --check: passed
• GitHub Actions: unit coverage, offline integration tests, lint, typecheck, CommonJS runtime, secret scan, and Codecov patch coverage passed
• Docker publish jobs stopped at registry login because fork PRs do not receive the repository credentials

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

[codecov]

Codecov Report

❌ Patch coverage is 87.50000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/services/workflow-validator.ts	87.50%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[czlonkowski]

Thanks for the focused fix. The Notion 2.2 path is valid, but I found one regression that should be addressed before merge.

src/services/workflow-validator.ts:656-658 applies getNodeVersion() to every versioned node. For persisted *Tool variants, the repository intentionally resolves version rows to the base node (src/database/node-repository.ts:902-912), while the variant schema adds toolDescription (src/services/tool-variant-generator.ts:67-89). The selected historical base schema therefore drops a valid variant-only property, and strict validation can emit:

Property 'toolDescription' won't be used - not visible with current settings

I reproduced this with n8n-nodes-base.googleCalendarTool at typeVersion: 1.3; the bundled database currently has 75 versioned stored Tool variants following the same base-version mapping.

Please preserve or merge variant-only properties when selecting the historical base schema (or handle nodeInfo.isToolVariant separately), and add a strict-profile regression test with a configured toolDescription. A missing-exact-version fallback test would also cover the currently untested branch.

One process item as well: AGENTS.md requires the exact attribution Conceived by Romuald Członkowski - https://aiadvisors.pl/en in both the PR description and commit message; both currently use www.aiadvisors.pl/en.

Local verification: 317 relevant validator/database tests and typecheck passed.

[justadityaraj]

Fixed in 212082f3:

• historical base schemas now retain the stored Tool variant's generated toolDescription
• added the strict googleCalendarTool 1.3 regression and missing-exact-version fallback coverage
• amended the commit and PR description to use the required attribution URL

Verified: 374 relevant tests, typecheck, build, and diff check passed. The full unit run still hits the existing Windows FTS5/symlink/shell limitations and does not exit cleanly.