n8n - 💡(How to fix) Fix Wait-node webhook resume returns SQLITE_ERROR: no such column: NaN (token treated as integer ID) [1 pull requests]

Reproducer

1. Create a workflow with a Wait node configured with resume: webhook and a fixed webhookSuffix: "approval".
2. Trigger the workflow so it pauses at the Wait node. Capture the resume token from the Wait node's emitted data (or from execution_data.data for the execution — it's a 64-char hex string).
3. POST to /webhook-waiting/<64-char-hex-token>/approval.

Expected: the Wait node resumes; downstream nodes execute.

Actual: HTTP 500 with body:

{"code":0,"message":"SQLITE_ERROR: no such column: NaN"}

n8n logs:

Error in handling webhook request POST /webhook-waiting/<token>/approval: SQLITE_ERROR: no such column: NaN

Diagnosis

In packages/cli/src/webhooks/waiting-webhooks.ts (built path: dist/webhooks/waiting-webhooks.js:135), the handler extracts the first URL segment as executionId:

const { path: executionId } = req.params;
// ...
const execution = await this.getExecution(executionId);

getExecution calls executionRepository.findSingleExecution(id), which runs findOne({ where: { id } }). typeORM coerces the value being compared to the integer id column via Number(). For a hex resume token like b03c253705c1c1edee0a81cef20abf979904b1ea4bda3e39bd4764dcafcc2af7, Number(token) is NaN. The SQLite driver then writes WHERE "id" = NaN into the SQL, which SQLite parses as a column reference (no NaN literal in SQLite SQL), producing no such column: NaN.

Environment

• n8n self-hosted 2.15.1 (latest stable at time of report)
• DB: SQLite (default)
• Workflow has Wait node with resume: webhook, webhookSuffix: "approval" (literal string, not an expression)
• Workflow is published (active) and firing on cron; the resume webhook is intended to be hit from a push-notification action
• 100% reproducible on every resume attempt

Suggested fix

Either:

1. Add a token-shape detection in the route handler — if req.params.path matches /^[a-f0-9]{64}$/, route to a token-resolution code path that looks up the waiting execution via the resumeToken, not by id.
2. Or, before calling findSingleExecution, validate that the value parses as a positive integer and 404 otherwise. Tokens should be resolved through a separate handler path.

Happy to draft a PR if the maintainer team confirms this is a real bug and shares which approach they'd prefer.

Related

Closed issue #23799 has a similar surface error but different root cause (user-supplied expression in webhookSuffix). This report is on the resume-token resolution path itself.