n8n 2.37.11 Release - Workflow Job Cleanup and External Secrets Guard

n8n published release [email protected] on September 7, 2026. This patch release resolves two core runtime stability issues in automated workflow executions, fixing worker job leaks when workflow executions reject and preventing active external secrets providers from being disabled when replacement connections fail. Operators running high volume workflow clusters or external credential integrations should update to avoid resource exhaustion and credential downtime.

The full release notes and downloads are on the GitHub release page.

In workflow orchestration runtimes, handling execution failures cleanly requires terminating all child tasks associated with a rejected execution promise. In previous releases of n8n, when a workflow run encountered an unhandled exception, syntax error in expression evaluation, or timeout rejection, the execution state transitioned to rejected without guaranteeing that active background jobs were cancelled.

Because running jobs remained attached to the worker process context, orphaned tasks continued consuming memory, CPU cycles, and database connection pool slots. Under sustained workloads with frequent webhook triggers or data processing failures, these leaked jobs accumulated over time, causing progressive memory pressure on worker pods.

Issue #37826 addressed this behavior in commit 257f0bb. The core execution subsystem now attaches explicit rejection handling hooks to the workflow execution promise lifecycle. When a workflow run rejects, the engine immediately invokes job teardown routines that cancel pending asynchronous operations, remove active jobs from memory tracking maps, and free database handles. This guarantees clean termination of worker tasks regardless of how the workflow failed.

n8n integrates with external secrets managers to retrieve credentials dynamically during workflow node execution. When operators update secrets configuration or rotate authentication keys, n8n reloads the active external secrets provider instance. Prior to version [email protected], initializing a replacement secrets provider would immediately tear down the existing serving provider before the new instance completed its connection handshake and validation checks.

If the replacement provider failed to initialize due to network failure, bad configuration keys, or upstream vault downtime, n8n was left without any active secrets provider. As a result, subsequent workflow runs requiring external credentials failed immediately, creating an outage across all workflows relying on external secret stores.

Pull request #37872 and commit 865fa12 modify the provider lifecycle in the core package. The secrets manager now maintains the existing serving provider in an active state while attempting to build and validate the new replacement provider. If initialization of the new provider fails, n8n logs the failure detail, retains the existing provider in service, and continues resolving credential requests without interrupting running workflows.

For platform engineers operating n8n in distributed multi worker configurations, these two fixes resolve key operational pain points. In distributed deployment modes using Redis queues and dedicated worker pods, orphaned jobs from uncleaned rejections previously required periodic pod restarts to free worker memory and prevent queue stall conditions. With explicit rejection cleanup, worker nodes release resources immediately upon job failure.

In enterprise environments with automated secret rotation pipelines, preserving the serving secrets provider eliminates service interruptions during routine vault updates. If a secret rotation script pushes a temporary invalid parameter or hits a temporary network glitch during provider reload, workflow processing continues seamlessly using the serving provider until the configuration issue is corrected.