Qdrant Vector Store works on 2.36.8 but not on 2.37.10

Questions
1

Hi,

I’m having an issue with the Qdrant Vector Store node after upgrading n8n.

I was running:

n8n 2.36.8

and Qdrant was working fine.

I upgraded to:

n8n 2.37.10

without changing anything else, and now the Qdrant Vector Store node fails.

The Qdrant server is self-hosted and I’m connecting to it over HTTP:

http://<SERVER-IP>:6333

with an API key.

The main error I’m getting is:

Api key is used with unsecure connection.
Failed to obtain server version. Unable to check client-server compatibility.
Set checkCompatibility=false to skip version check.
fetch failed

I’m also seeing:

TypeError: fetch failed

and:

InvalidArgumentError: invalid onError method

I checked Qdrant separately and it’s responding normally:

curl http://<SERVER-IP>:6333/collections

So the interesting part is:

2.36.8 → works

2.37.10 → fails

Same Qdrant, same URL, same API key, same Docker setup and same workflow.

Has anyone else seen this with 2.37.10? Is there something that changed in the Qdrant node/client between these versions?

2

Hey @Yash_Nerkar, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@shouchi_migari, @jabbson, @Jack - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Update: I tested this further and it looks like the issue is not specific to n8n 2.37.10.

I’m actually seeing the same fetch failed issue on n8n 2.36.8 as well.

The interesting part is that the Qdrant Vector Store works fine when I run the workflow using Test/Manual execution, but I’m getting the fetch failed error when the workflow runs as a production execution.

So currently the behavior is:

  • n8n 2.36.8 + Test execution → :white_check_mark: works
  • n8n 2.36.8 + Production execution → :cross_mark: fetch failed

The Qdrant server, URL, API key and workflow are the same.

The error I’m getting is:



fetch failed

Along with:



Api key is used with unsecure connection.
Failed to obtain server version.
Unable to check client-server compatibility.
Set checkCompatibility=false to skip version check.

And in some cases:



TypeError: fetch failed

I’m running n8n self-hosted in Docker/queue mode.

So I’m wondering if this could be related to production executions/workers/concurrency or the way the Qdrant connection is being made from the worker, rather than the n8n version itself.

I’ve attached a screenshot from the production execution showing the error.

Has anyone seen this difference between manual/test execution vs production execution with the Qdrant Vector Store node?

4

We have taken a look at this and it looks like it might be fixed in a recent release, Please update and see if you are still running into the same problem.

5

Hi @Yash_Nerkar
Manual runs execute on the main instance and production runs execute on a worker, so what changed between your two tests is which container opened the connection, not the version. Your main can reach Qdrant and your worker cannot, which is also why upgrading will not move this.
fetch failed is a connection-level failure with no HTTP response behind it. The other lines are noise. The unsecure-connection line is a warning the Qdrant client always prints for an API key over plain HTTP, and the version-check line is what follows once the fetch has already failed, so checkCompatibility=false will not help.
Test from the container that is actually failing, using the same fetch the node uses:

docker exec -it <your-worker-container> node -e "fetch('http://<SERVER-IP>:6333/collections').then(r=>console.log(r.status)).catch(e=>console.log(e.cause))"

If that fails while the same command in the main container succeeds, the worker is on a different network or has no route to that IP, and the fix is in your compose file rather than in n8n.

6

Hi, I have the same problem. I’ve checked everything multiple times but I can’t find what’s wrong. I’ve opted for a solution suggested by Claude, which is to use a build with an earlier version of Node, which is supposed to fix this “bug”. If you could confirm which versions of n8n and Qdrant don’t have errors, it would help me a lot to stay up to date. Thanks.

7

Hi @Tomas1
There is a real bug behind this and it has a name. n8n bundles @qdrant/js-client-rest at 1.16.2, which breaks two separate ways on Node 26. Its compatibility check rejects Qdrant servers on 1.19.x, and its pinned undici v6 dispatcher clashes with Node’s own fetch, which is where invalid onError method comes from. Those are tracked as 37907 and 37903.
So no pairing of n8n and Qdrant versions is simply safe. Downgrading Node only addresses the dispatcher half, leaves the server-version half untouched, and hands you a custom image to maintain. Holding your Qdrant server below 1.19 is the lighter stopgap.
The repair merged on 3 September as 37758, moving the client to 1.19.0 and dropping the undici pins. That is the thing to watch rather than a version chart.
@Yash_Nerkar this bears on your case too. The invalid onError method line in your first post is that dispatcher clash, so it is worth ruling this in before chasing the worker’s network.