fixmation.Get my quote
n8n14 min readPublished October 2026

The n8n Qdrant fix that was "already released" was on a track you were not on

From 2 September, RAG workflows on n8n Cloud and self-hosted 2.37 and 2.38 failed at the Qdrant Vector Store node with "fetch failed" while the credential test stayed green and an HTTP Request node reached the same server. The cause was a Node 26 image n8n shipped without a release note, the fix was merged on 4 September, and for the following week "please upgrade, this is already fixed" meant a beta build that Stable and the default Docker tag did not carry. On n8n's release rhythm the fix should have reached every track long before you read this, except a pinned 2.37 or 2.38 - and the credential test still cannot tell you which you are on.

Green test, dead node

On 2 September a RAG workflow on n8n Cloud ran successfully at 17:00 UTC and failed at 23:00 UTC, with nothing changed on its owner's side. 2.37.7, the first Stable release of the 2.37 line, had been published at 08:41 UTC that morning. The fullest description of what he and the reporters after him were looking at came a week later, from a self-hosted instance on 2.38.5:

Qdrant credentials still test successfully (Connection tested successfully). Direct HTTP from the same containers to Qdrant also works (GET /collections → 200). The credential test uses n8n's HTTP helper. The Vector Store node uses @qdrant/js-client-rest@1.16.2, which creates an undici 6 Agent and passes it to Node's built-in fetch. n8n 2.38 ships Node 26, which bundles undici 8. Mixing them throws: InvalidArgumentError: invalid onError method [...] n8n then surfaces only fetch failed, so it looks like a connection/credential problem.

Seventy-four seconds after it was opened, an n8n staff member replied "can you try updating this should be fixed in the newest release" and closed it as a duplicate. On 9 September the newest release that contained the fix was 2.39.1, a beta. The newest Stable release was 2.38.5, and two days later 2.38.7 was published and tagged stable and latest; neither had it.

Between 3 and 11 September, fourteen issues were opened on n8n's GitHub about this and one thread on its forum; counting the people who wrote "same here" in them, about two dozen different users reported it. The pull request that fixed it estimated the population before most of them had posted: "~148 events, ~127 users" in n8n's own error telemetry. Every report reads the same. The RAG agent that worked yesterday fails today at the Qdrant Vector Store node with NodeApiError: fetch failed. The credential's Test connection button is green. curl from inside the container gets a 200. An HTTP Request node pointed at the same host with the same key works.

Why a green test proves nothing here

The test and the node do not share an HTTP client; everything below follows from that.

The Qdrant credential's test is declared in five lines of QdrantApi.credentials.ts: a GET to /collections on the configured URL. n8n runs it through its generic request helper, which is axios on Node's own http module, sending the User-Agent n8n. One user pulled his Qdrant Cloud access logs and saw exactly that: GET /collections HTTP/1.1 200 User-Agent: n8n for the requests that still got through, and POST /collections/.../points/query 200 User-Agent: qdrant-js/1.16.2 for the last workflow run that worked. After 2 September the second kind of line stopped appearing. The requests from the node were not reaching the server.

The node itself imports QdrantClient from @qdrant/js-client-rest, version 1.16.2 as pinned in n8n's workspace file, and that client builds its own connection Agent from its own copy of a library called undici, version 6, and hands it to Node's built-in fetch. Node 26 bundles undici 8 - Node 24 shipped undici 7 - and its fetch rejects the version 6 agent before a socket is opened. The pull request that fixed it describes the failure in one sentence:

The global fetch of Node >= 26 rejects a dispatcher built from undici v6 (invalid onError method). Any node that hands such an Agent to the global fetch fails every request with an opaque NodeApiError: fetch failed.

"Opaque" is the word for it. The node's error handler, in a shared file every vector store node uses, wraps whatever the client threw in a NodeApiError and copies only its message - fetch failed - discarding the cause where invalid onError method lives. That line reaches the worker log and nothing else. From the editor you see a connection failure on a connection the test just proved works, and the collections dropdown reads "Could not load list".

The HTTP Request node works because it uses the same helper as the credential test. So does a community-maintained Qdrant node package, which several reporters used to prove the server was fine. What broke is the one node that talks to Qdrant through Qdrant's own client, on an image that had changed underneath it.

Node 26 arrived in 2.37 without a release note

The image switch was PR #36291, "build: Switch n8n image to Node 26", by an n8n engineer, merged on 19 August: the builder and runtime move to Node 26.5.1, and the only rationale it links is an internal page titled "Halving memory usage via pointer compression". 2.37.0, the first beta on it, went out on 25 August; the 2.38 line, from 2.38.1 on 1 September, moved to 26.7.0. The release notes for 2.37 on docs.n8n.io list sixteen items and do not mention Node.js or the runtime version; neither does the GitHub release. It is the same Node 26 migration behind the Code node breakage on 2.37.1 - that one came through the task-runner image, a separate pull request, as a native library missing from the new base - and that was patched in a day. This one was not, because it was not n8n's code.

Node 26 itself was not a long-term-support release when n8n adopted it; its LTS date is 28 October, six days after this article appears.

The dependency that could not cope with it had been fixed upstream before n8n moved. Qdrant's JavaScript client had an issue open since 12 May with the exact error text in its title, closed on 5 August by a release, 1.19.0, that builds its agent from undici 7. That is fifteen days before the image switch. n8n's pin stayed at ^1.16.2 until 4 September.

What "already fixed" meant, day by day

The Qdrant half of the fix, once it came, was one line in the workspace file: the pin moves to ^1.19.0. It was merged into master on 4 September. Then:

  • 7 September. A contributor on the busiest issue posted the state of every build: "Fixed on master in 325feb3ba6 (#37758), but not in any released build, including today's 2.38.4. [...] The 2.38.x release branch forked from master on Sep 1 [...] and the fix landed on Sep 4, so it is not picked up automatically. There is no backport branch or PR, which puts it in 2.39.0. Upgrading within 2.37.x or 2.38.x does not help [...]" He asked whether a backport was possible, since "the Cloud users on this thread cannot work around it themselves". No one from n8n answered.
  • 8 September, 07:00 UTC. n8n's issue bot closed four of the issues with "This issue has been resolved and the fix will be included in an upcoming release." At 08:25 UTC 2.39.0 was published, as a beta, with the fix in its changelog. (Between 7 and 11 September the same bot closed three more on sight as support requests; one author answered "I disagree with your response and the closure of this ticket.")
  • 9 and 10 September. A staff member closed five issues as duplicates with "please upgrade this should already be fixed", "a fix went out earlier this week", and, two minutes after saying the fix "should be available soon", "it looks like it is actually already available and an update should resolve this". On a Cloud workspace one of those users did what he was told:

I just checked I have to upgrade my account to 2.39 to a pre release version which is not stable and not on cloud so how is this exactly already fixed ? Is there something I am missing here

  • 11 September. 2.38.7 was published and tagged stable and latest with three bug fixes, none of them this. A self-hosted user who had been told to update wrote: "I'm daily on the latest docker image but as of today I can't confirm the fix found its way into the image." He was right. 2.39.4, tagged beta and next the same morning, had it.

The Mistral Chat Model node has a sibling story in the same weeks and the same release. A change merged on 14 August to prepare n8n's own AI fetches for Node 26 - described in its pull request as "no behavior change, nothing affecting users, but a latent bug" - broke the Mistral node in the 2.36 line (first reported on 2.36.5, working on 2.35.4) with Failed to parse URL from [object Request], on Node 24, before the image switch. Its fix was merged on 7 September and is also in 2.39.0. On the forum, n8n's forum bot told a Cloud user on 7 September that "it looks like it might be fixed in a recent release, Please update"; the fix had been merged three hours earlier and released nowhere. Two days later, on the Beta track, that user got 2.39.0 and confirmed it worked.

What this looks like on 22 October

Checked on 12 September, Stable was 2.38.7 and Beta 2.39.4. n8n cuts a new minor as a beta every Tuesday - 2.34.0 on 4 August through 2.39.0 on 8 September without a gap - and has promoted each previous minor to Stable three to eight days later. If that rhythm held, 2.39 reached Stable in the middle of September, the Stable track is several minors past it today, and an instance that follows a track, Cloud or latest, has had the fix for about a month. If it did not hold, the version to look for is still 2.39.0 or later.

Two kinds of instance are still where 9 September left them. A self-hosted instance pinned to any 2.37.x or 2.38.x tag: those lines got patches, but never this one, and will not, since n8n patches a minor only until the next one is promoted. And any instance that was rolled back to 2.36.9 - the last release on Node 24, which several reporters confirmed works - and left there, which on the same rhythm now means being seven or more minors behind, with everything in the fortnightly security releases since.

"Is it fixed" is the wrong question; the credential test cannot tell you which build you are on, and that is the one that matters.

Read the version, then click the dropdown

  1. Read the version, not the track name. Self-hosted: the image tag in your compose file or the version in Settings. Cloud: the version dropdown under Updates & maintenance, described in the earlier article. Anything from 2.37.0 to 2.38.7 inclusive has the bug and no patch coming. 2.36.9 and below do not have it and do not have anything since 31 August. 2.39.0 and above have the fix.
  2. Test the node, not the credential. Open a Qdrant Vector Store node and click the collection dropdown. "Could not load list / fetch failed" on a server the credential test reaches is this bug, and it is the cheapest reproduction there is - no workflow has to run. A working dropdown on a build between 2.37.0 and 2.38.7 means you are not on the image you think you are.
  3. If you are on a pinned 2.37 or 2.38, move. Forward to the current Stable is the normal answer. Back to 2.36.9 is a Node 24 image with a known set of missing fixes, and a stop, not a destination.
  4. If you built the HTTP Request workaround in September, decide whether to keep it. Two reporters rebuilt the node's insert or query as raw REST calls to Qdrant, and it worked, and a third confirmed the same requests went through an HTTP Request node; it also drops the node's embedding sub-node and its "retrieve as tool" mode, so an agent that used those has been running on a different design since. Once on 2.39.0 or later, the original node is the simpler thing to maintain.
  5. If a node fails with a bare fetch failed and a green test, read the worker log. The line with the real reason - here, invalid onError method
    • is written there and nowhere in the editor. The handler that discards it was not changed by this fix, and the contributor who traced it said what that means: "the next SDK that fails this way will again surface as a bare fetch failed."

An instance that is on the wrong build, or on a September workaround that has outlived its reason, is a short n8n job with a price on it; what takes the time is usually establishing which of the two it is.

Sources

Broken workflow? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.