n8n published [email protected] on October 2, 2026, with a core fix that keeps the task runner running after an unhandled promise rejection. For operators using n8n in ETL and web processing pipelines, the change addresses runner availability when asynchronous work fails. GitHub marks this as a regular release, not a prerelease.
The full release notes and downloads are on the GitHub release page.
Task runner survival after a rejection ¶
The release lists one bug fix. Its stated behavior is precise: an unhandled promise rejection should leave the task runner running. The notes reference #40092 and commit d719c87. This is an execution runtime change, with an observable result for operators.
The failure symptom addressed here is loss of the running task runner. The trigger is an unhandled promise rejection. The notes do not identify which workflow operations produce that rejection, describe the underlying code defect, or establish how much other work a runner exit affects. Those details matter when matching this fix to an incident. A workflow error alone is insufficient evidence that an installation has encountered this bug.
The useful comparison is the runner’s behavior around the rejection. If incident logs show both the rejection and a runner exit, this release is relevant to the investigation. The announced correction is continued runner operation after that event. There is no separate claim that the asynchronous operation which rejected now succeeds.
Process availability and pipeline results ¶
For a data pipeline, runner availability and successful execution are separate checks. A process can remain alive while a task fails. This patch changes the stated response to an unhandled rejection, but the release notes make no promise about retries, replay, output completeness, or the final state of the affected execution.
That distinction should shape how operators judge the result. A reduction in runner exits would support the availability claim. It would not, by itself, show that a destination received all expected records. Where a workflow writes data, inspect its execution result and destination output separately from runner uptime.
There is also an observability consequence to check. If a local alert depends on runner termination, continued operation may remove that signal while the original rejection still needs attention. During validation, check whether the failure remains visible through the execution status or available logs. This is an operational implication of keeping the runner alive, not an additional logging feature announced in 2.41.6.
Validate the rejection path ¶
For installations with a reproducible case, a useful staging check is to run that case against 2.41.6 and observe the runner through the rejection. Record whether it stays running, how the affected execution ends, and whether subsequent work completes. These checks test the advertised behavior and help distinguish process survival from useful continued operation.
Use an isolated destination if reproducing the workflow can write records. Compare the expected output with the actual result before treating the incident as resolved. The release provides no benchmark or quantified recovery improvement, so there is no published performance target to validate.
The notes list no migration steps, configuration flags, or breaking changes. They also contain no additional fixes to assess. The decision to deploy this patch rests on the task runner failure path and its relevance to the workloads an installation runs.