n8n - 💡(How to fix) Fix Regression in 2.19.0: parent execution with `saveDataSuccessExecution: 'none'` returns 404 when a sub-workflow resumes it via `/webhook-waiting/<execId>` [1 comments, 2 participants]

Bug Description

Describe the bug

Since upgrading to n8n 2.19.0, a workflow that:

1. has saveDataSuccessExecution: "none" (UI: Save successful production executions → Do not save),
2. uses a Wait node in resume: "webhook" mode,
3. is resumed by a sub-workflow (or any external caller) that POSTs to https://<host>/webhook-waiting/<parentExecutionId>?signature=...,

…fails at resume time with: NodeApiError: The resource you are requesting could not be found httpCode: 404 404 - {"code":404,"message":"The execution "<parentExecutionId>" does not exist."}

The parent execution row is no longer queryable via the public API (GET /executions/<id> also returns 404), as if it had been pruned/never persisted before the resume call hits the server.

Toggling the workflow setting back to Save makes the issue disappear. This is a 100% reproducible workaround.

To Reproduce

Minimal repro:

1. Create a parent workflow A with a Wait node (Resume = On webhook call). Configure workflow settings:
   • Save successful production executions → Do not save
2. Create a sub-workflow B that is called by A via Execute Workflow, and that POSTs to the parent's resume URL https://<host>/webhook-waiting/ $execution.parentExecution.id ?signature=... after doing some work.
3. Trigger A.
4. The sub-workflow gets a 404 - The execution "<parentExecutionId>" does not exist. from the resume endpoint.
5. Switch A's setting to Save → re-run → resume succeeds.

Expected behavior

A parent execution that is in waiting state must remain resolvable by /webhook-waiting/<execId> regardless of saveDataSuccessExecution. The none setting should only apply after the execution reaches a terminal state, not while it is still waiting for a webhook resume.

In 2.18.x and earlier this is the case.

Your n8n setup

• n8n version: 2.19.0
• DB: Postgres
• Execution mode: own (non-scaling)
• OS / deployment: Docker, self-hosted
• Browser: n/a (failure is server-side)

Suspected root cause

Two PRs landed in 2.19.0 that both modify packages/cli/src/execution-lifecycle/execution-lifecycle-hooks.ts, specifically the workflowExecuteAfter hook that decides whether/when to persist an execution:

1. feat(core): Add audit logs for webhook waiting and resuming (#28204)

This PR explicitly amends the workflowExecuteAfter hook to add a new branch for runData.status === 'waiting'. From the PR description:

"in the workflowExecuteAfter hook we amended inside execution-lifecycle-hooks.ts, there is now a new event being emitted for this waiting case." "Disclaimer: lots of code was written by Claude. I thoroughly reviewed and amended the code."

The series of corrective commits during review (Fix bug where workflow.resumed event comes immediately after workflow.waiting for "wait for form" node, Only emit execution-waiting event for webhook waits, Also exclude sendAndWait nodes from initial execution-waiting implementation, Defensively get resumedNode for waiting executions) suggests the interaction between this hook and the various waiting-node flavours was non-trivial to stabilise. Cubic also flagged a residual P2 just before merge:

"Timer-based resumes no longer emit the resumed audit event."

This is the most likely culprit because it's the only PR that explicitly modifies the status === 'waiting' code path in the hook responsible for execution persistence.

2. fix(core): Persist execution metadata for failed executions in scaling mode (#28774)

This PR changes the early-return guard in the same hook from if (!finished) return to if (!terminalStatuses.includes(status)) return, where terminalStatuses = ['success', 'error', 'crashed', 'canceled']. 'waiting' is not in that list, so the persistence path for waiting executions now follows a new branch that may interact with saveDataSuccessExecution: "none" differently than 2.18.

Quoting the PR:

"the workflowExecuteAfter hook on the main process returned early whenever the deprecated finished flag was falsy. […] The guard now checks status against the terminal statuses (success, error, crashed, canceled), matching how regular mode already behaves."

Even though this PR is officially about scaling mode, it changes the shared hook that own-mode also relies on. Combined with #28204's new waiting-branch logic, the net effect appears to be that a waiting execution on a saveSuccess: "none" workflow is no longer kept alive long enough for the resume call to find it.

Workaround

Set Save successful production executions = Save on every workflow that uses Wait-on-webhook. Acceptable short-term but inflates the executions table for users who relied on none to keep it small.

Severity

High for self-hosted users with Wait-on-webhook patterns and aggressive execution pruning. Silent data loss / silent workflow breakage on upgrade.

To Reproduce

no

Expected behavior

no

Debug Info

no

Operating System

Ubuntu

n8n Version

2.19.0

Node.js Version

24.0.0

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted