n8n 1.123.65 - Webhook Error Handling Fix

n8n [email protected] was published on 2026 07 13 with one core fix: webhook execution promises now settle when early errors occur. For teams using n8n as a web processing and workflow entry point, this is a small release about failure closure, not new surface area.

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

The release notes list a single bug fix in core: settle the webhook execution promise on early errors. The linked issue is #33998, and the fix is tied to commit ec985f4.

That sounds small because it is small. It also sits in a path that matters. Webhooks are often the boundary between external systems and internal workflow state. A stuck or unresolved execution promise can make a failed request look less final than it really is, especially when callers retry, gateways hold connections, or an operator is reading logs during an incident.

For data engineering use, this matters when n8n is used as glue around ingestion jobs, enrichment hooks, CRM exports, webhook based event intake, or low volume control plane automation. The release does not claim a new retry model or new webhook semantics. It closes an error path that should already have had a clear end state.

Early errors are awkward in automation platforms because they happen before the usual work has started. At that point, a workflow may not have useful node output, a caller may only see a transport level symptom, and queue or process state may not tell a clean story.

Settling the promise gives the runtime a better chance to finish the request path predictably. That is useful for reverse proxies, health checks, custom clients, and any wrapper process that expects failed webhook execution to return control. In production terms, the value is not feature count. The value is less ambiguity when a webhook request dies before normal execution.

This also affects observability. When an execution path does not close cleanly, alerting and logs tend to become noisy. Operators may see symptoms around latency, hung requests, or missing completion records before they see the actual root cause. A direct fix in core keeps the remediation close to the boundary where the bug appears.

This is not a broad release. The notes do not mention database migrations, credential changes, node behavior changes, API changes, or queue worker changes. They also do not describe a breaking change. The release is not marked as a prerelease.

That narrow scope is useful if you are carrying [email protected] and have webhook paths that can fail during request setup. The previous recent version covered on this site was [email protected], so this post is only about the follow up fix in [email protected].

The practical upgrade check is simple. Exercise representative webhook workflows that fail before normal node execution. Include bad payloads, missing headers, rejected auth paths, and intentionally broken downstream references if those are part of your environment. Watch for request completion, response status, logs, and execution records.

If n8n is behind nginx, an ingress controller, or an API gateway, also check timeout and retry behavior. The release note does not say that gateway level behavior changes. Still, a cleaner application side completion can change what upstream components observe during failure tests.