n8n - ✅(Solved) Fix Sub-workflows that are configured as 'Do not save' are still appearing as running in Postgres [1 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
n8n-io/n8n#28867Fetched 2026-04-23 07:44:21
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Author
Timeline (top)
commented ×2labeled ×1mentioned ×1subscribed ×1

Root Cause

In database the execution should appear as success or should not appear at all because the execution should not be saved

PR fix notes

PR #29027: fix(core): Set terminal execution status when pruning unsaved runs

Description (problem / solution / changelog)

Summary

Sub-workflows that finish successfully with "Save successful production executions = Do not save" (or error with error-saving disabled) used to leave their DB row at status='running' until the next pruning hard-delete swept it. The UI, executions endpoints, and any Postgres/SQL inspection therefore showed finished sub-workflows as still running.

Root cause lives in ExecutionPersistence.deleteInFlightExecution (packages/cli/src/executions/execution-persistence.ts). The soft-delete branch only wrote a backdated deletedAt:

await this.executionRepository.update(target.executionId, { deletedAt });

fullRunData.status had already been finalized by hookFunctionsFinalizeExecutionStatus before this call, but it was being discarded. The row retained the 'running' status it had when the execution started.

This PR threads the terminal status, finished flag, and stoppedAt from the completed run through deleteInFlightExecution and into the UPDATE, so the row immediately reflects the real outcome:

await this.executionRepository.update(target.executionId, {
  deletedAt,
  status,
  finished,
  stoppedAt,
});

Both call sites in execution-lifecycle-hooks.ts (hookFunctionsSave and the delete branch in getLifecycleHooksForScalingMain) forward those fields from fullRunData.

Scope of the change

  • Touched only packages/cli/src/executions/ and packages/cli/src/execution-lifecycle/ — no changes to packages/core, no frontend, no node changes.
  • 2 production files, 2 test files, +108 / -30 LOC.
  • No new public API or new package dependencies.
  • Pruning schedule, hard-delete path, and metadata-on-keep guard are unchanged.

Testing

  • packages/cli/src/executions/__tests__/execution-persistence.test.ts — the existing "soft-delete with backdated deletedAt" test now asserts the full UPDATE payload including terminal status, a new 'error'-status variant covers the error path, and the hard-delete test supplies the now-required run-status argument.
  • packages/cli/src/execution-lifecycle/__tests__/execution-lifecycle-hooks.test.ts — the three deleteInFlightExecution call-site assertions in getLifecycleHooksForScalingMain verify the new second argument is forwarded from fullRunData.

Local run:

pnpm jest src/executions src/execution-lifecycle
Test Suites: 17 passed, 17 total
Tests:       246 passed, 246 total

Related Linear tickets, Github issues, and Community forum posts

Fixes #28867

Review / Merge checklist

  • PR title and summary are descriptive
  • Docs updated (N/A — internal persistence helper, no public docs or node surface)
  • Tests included
  • Backport label if urgent fix

Changed files

  • packages/cli/src/execution-lifecycle/__tests__/execution-lifecycle-hooks.test.ts (modified, +41/-15)
  • packages/cli/src/execution-lifecycle/execution-lifecycle-hooks.ts (modified, +24/-10)
  • packages/cli/src/executions/__tests__/execution-persistence.test.ts (modified, +29/-3)
  • packages/cli/src/executions/execution-persistence.ts (modified, +14/-2)
RAW_BUFFERClick to expand / collapse

Bug Description

In postgresSQL sub workflow with setting 'Do not save' are never updated as success in bdd and the deletedAt field have a date previous to the date createdAt

Ex startedAt status deletedAt createdAt "2026-04-22 08:02:57.866+00" "running" "2026-04-22 07:02:58.062+00" "2026-04-22 08:02:57.831+00"

<img width="713" height="167" alt="Image" src="https://github.com/user-attachments/assets/4344fda9-bfa4-42c5-b181-ee077f4bad0b" />

To Reproduce

1 Create a WF 2 In the WF call a sub WF (not a webhook) 3 Set the setting of the sub WF to "Do not save" 4 Run as many as you can the sub WF 5 Check in database the WF have the status running

<img width="1339" height="400" alt="Image" src="https://github.com/user-attachments/assets/fc3f1055-eb3f-4aa7-b1e9-593c67105e73" />

Expected behavior

In database the execution should appear as success or should not appear at all because the execution should not be saved

Debug Info

After a while the executions are "hard deleted" and desapear of the database but it's a bit confusing that during a while we have plenty of execution as "running" in database

<img width="1443" height="118" alt="Image" src="https://github.com/user-attachments/assets/0509d6af-6e0f-440a-ad0e-653c3aa7f0bc" />

Operating System

Redhat

n8n Version

2.17.3 docker image

Node.js Version

v24.14.1

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted

extent analysis

TL;DR

The issue can be mitigated by investigating the PostgreSQL database configuration and the n8n workflow settings to ensure that the "Do not save" setting for sub-workflows is properly handled.

Guidance

  • Investigate the n8n workflow settings to confirm that the "Do not save" setting for sub-workflows is correctly configured.
  • Check the PostgreSQL database configuration to ensure that it is properly handling the deletion of workflow executions.
  • Verify that the deletedAt field is being updated correctly when a workflow execution is completed.
  • Review the n8n version and Node.js version to ensure that they are compatible and up-to-date.

Example

No code snippet is provided as the issue is related to configuration and database settings.

Notes

The issue may be related to the way n8n handles sub-workflow executions and the "Do not save" setting. Further investigation is needed to determine the root cause of the issue.

Recommendation

Apply workaround: Investigate and adjust the n8n workflow settings and PostgreSQL database configuration to ensure proper handling of sub-workflow executions with the "Do not save" setting. This is recommended as the issue is likely related to configuration and database settings, and adjusting these settings may resolve the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

In database the execution should appear as success or should not appear at all because the execution should not be saved

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

n8n - ✅(Solved) Fix Sub-workflows that are configured as 'Do not save' are still appearing as running in Postgres [1 pull requests, 2 comments, 2 participants]