Yes. N8n is in a container and is able to resolve the host name.
The questdb node is working fine and I am able to access Questdb. But I need to use http node in my workflow.
That is a bit odd, So the getaddrinfo EAI_AGAIN error tends to show up when the hostname being used can’t be resolved and tends to point to a network issue but the node working is really strange.
Have you tried using the IP address instead of the hostname? What version of n8n are you running as well?
Hi @Dhanya_V_Sagar, I am so sorry to hear you are running into trouble here. I quickly gave this a go and can query QuestDB just fine using the HTTP Request node in a workflow like this:
So as mentioned by @Jon the first thing that comes to my mind here would indeed be an issue with your docker/networking setup. Are you using the QuestDB node on the same n8n instance as the HTTP Request node? What error exactly were you getting when using the IP address of your QuestDB server in the HTTP Request node?
Can you query your QuestDB from a shell within your n8n docker container (for example by first running apk add curl and then making a curl request such as curl 'https://demo.questdb.io/exec?query=pos%20latest%20by%20id%20where%20geo6%20within(%23wtq)%3B' where https://demo.questdb.io is the URL of your QuestDB server)?
The HTTP Request node is looking good to me - pretty much what I was doing in my example.
One thing worth pointing out is that QuestDB uses a number of different ports and for the HTTP Request node you’d need the one of the REST API. By default this would be 9000 but might differ in your setup (the ECONNREFUSED 172.19.0.9:80 error suggest you were querying port 80).
So my suggestions for the next steps here would be to verify you are querying the right port for QuestDB’s REST API and also make sure to try querying the REST API with plain http instead of https.