How to solve ECONNREFUSED error — service can not reach the other service

I have been assigned to a task that required me to create a new topic and a subscriber, which would listen to it. Whenever a new message was published by the topic, the subscriber was supposed to act on it and call proper API endpoints. After writing all required unit tests, I was sure things will not fall into pieces, so I happily created a preview branch and pushed out changes to it.

Source: https://unsplash.com/photos/szPxqGFNS6Y

The CI/CD pipeline went all green, the tests have passed, and soon I could see on the GCP my brand new environment. I went to the topic to publish a message. Did my part, even did not forget to set up a proper attribute under the message body. Nothing bad can happen if the message did not get unexpectedly nack’ed, right? No.

… oh well, an ECONNREFUSED appeared in the workload which is supposed to handle the actions after the message is received.

Config and queue setup

In my setup each branch which has a specific preview prefix triggers a test environment, which is shut down automatically after several hours if no other code contribution is made to it. I also use config files, where I define specific variables for our environments. It is very handy when you want to enable/disable a feature flag, or you just simply want to change the time length for acking the Pub/Sub messages. So, just like that, in integration.json you are able to make some major changes and check out how the whole software reacts to it.

ECONNREFUSED error appeared

When I saw that my message did not go unexpectedly nack’ed I found it in the corresponding Worker workload logs. I was quite surprised that the logging was indicating that the whole process only received the message, and started validating it. Nothing beyond that. I knew that because I logged out every step of the function cycle. When I opened the JSON payload, I could see that a body of an error bloomed in it. Yay.

I was looking at a ECONNREFUSED error, and now I know it’s clear that it is a connection issue, but those two weeks ago it wasn’t that obvious. I got into a mild panic attack, since I had no idea what to do with it. How come I’m supposed to fight with GCP Pub/Sub’s connections now? The thing was that I was not supposed to fight with GCP Pub/Sub’s connections, but with my own configuration. The Pub/Sub worked just fine.

I am fortunate enough to have patient and supporting teammates who pointed me to the right place and explained why things are not working the way they’re supposed to. My issue was that my config/preview.json file looked like that:

Here, the preview environment does not know to which service to connect to, so an output it doesn’t know which API to call. The three line solution is introducing to the preview.json configuration file the origin of the API, so the service know to which other service to connect to. Because the logic triggered in the message was involving the API, I needed to point it in the right direction:

The “tricky” part in all of this, was that the issue is multi-repo specific, at least with my setup. In a monorepo (where I was working before), if you deploy a preview environment, the CI/CD will build everything from scratch under the preview environment. That’s the way the CI/CD pipeline is built. This means that your Pub/Sub Workers, the API and everything else you have in there will be built without you sweating.

Another solution to this whole issue would be to create another preview environment for the API. So I should find the API repository that I wanted to connect to, create a preview branch there, and push it out. It would have to have the same branch name, though, so GCP knows that those two are connected.

Summing up on “How to solve ECONNREFUSED error“:

• In your config file specify which API should be used by the preview environment
• Create another preview branch in the API repository with the same name, so the GCP knows those two are connected