Unsuccessful: null read ECONNRESET

[gdeichen]

I get this error consistently on one Ubuntu Server installation, even though it works on several others. Any idea how I can debug it? Thanks.

Unsuccessful: null read ECONNRESET

[gdeichen]

This is the response to a simple mailjet post / request, basically the same as this: https://github.com/mailjet/mailjet-apiv3-nodejs#simple-post-request

[bhavelyn]

We are getting the same error as well

[adrienthiery]

Same error here. We have this issue when running on AWS Lambda, but everything works fine locally or from a docker container running... Any clue on how to debug/solve this ?

cc @andrii-yelis maybe ? 😅

[LouisLec]

Same here, it suddenly stopped working... is there a rate limit or something we are not aware of ?

[gdeichen]

It's not a rate limit problem; there is a (silent!) limit of 200/day for the free tier, but the emails go through to the queue without an error.

I got around this by building a new VM from scratch. So it's some kind of library conflict or whatever, but there's nothing in any logs that give me a clue to what the issue is.

[adrienthiery]

For us, it "started working again" next day, or at least started giving us a "real error", being that we did not initialize the SDK correctly 🤷

Not sure if it was because of that or something else

[LouisLec]

Thx @gdeichen,

there is a (silent!) limit of 200/day for the free tier

I'm not on the free tier and was far from 200 that day 😢

Anyway it's working again so there must be a limit somewhere...

[alex-r89]

I have also just had this issue. No emails are sending at all at the moment. I'm on the free tier but have not sent an email for days.

Any idea whats causing it? The full error im seeing is:

Error: Unsuccessful: null read ECONNRESET
    at /root/service-backend/node_modules/node-mailjet/mailjet-client.js:331:23
    at Request.callback (/root/service-backend/node_modules/superagent/lib/node/index.js:905:3)
    at ClientRequest.<anonymous> (/root/service-backend/node_modules/superagent/lib/node/index.js:822:12)
    at ClientRequest.emit (node:events:394:28)
    at ClientRequest.emit (node:domain:470:12)
    at TLSSocket.socketErrorListener (node:_http_client:447:9)
    at TLSSocket.emit (node:events:394:28)
    at TLSSocket.emit (node:domain:470:12)
    at emitErrorNT (node:internal/streams/destroy:193:8)
    at emitErrorCloseNT (node:internal/streams/destroy:158:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  ErrorMessage: 'read ECONNRESET',
  ErrorIdentifier: undefined,
  statusCode: null,
  response: null
}

EDIT: about 2 minutes after posting this, and continually trying to send emails, it started working again. Its almost like some service was spinning up to send emails for my account. Very strange.

[CardonaPablo]

Having the same problem here with the post API. It stopped working about a week ago, I'm using the same keys in staging and production, oddly, the production mails are working properly but staging doesn't seem to send anything. EDIT: 4 Hours after posting, emails suddenly work again

[boldtrn]

This sounds like the Mailjet API is having some issues right now? We have seen this errors from time to time as well, this seems to happen infrequently, but still it is not reliable.

[roger1345]

Im having the same issue, we are using the Mailjet API in some gcp cloud functions and it was working before for along 2 years, and not it is sending few mails but not all. We are seeing the same ECONRESET message :/

Any idea on how can we solve the issue? some kind of rate limit issue? we are not using the free tier btw

[danielluca]

Experiencing the exact same issue. We use also GCP Cloud Functions.

Error: Unsuccessful: null read ECONNRESET
    at /workspace/node_modules/node-mailjet/mailjet-client.js:331:23
    at Request.callback (/workspace/node_modules/superagent/lib/node/index.js:905:3)
    at ClientRequest.<anonymous> (/workspace/node_modules/superagent/lib/node/index.js:822:12)
    at ClientRequest.emit (events.js:400:28)
    at ClientRequest.emit (domain.js:475:12)
    at TLSSocket.socketErrorListener (_http_client.js:475:9)
    at TLSSocket.emit (events.js:400:28)
    at TLSSocket.emit (domain.js:475:12)
    at emitErrorNT (internal/streams/destroy.js:106:8)
    at emitErrorCloseNT (internal/streams/destroy.js:74:3)
    at processTicksAndRejections (internal/process/task_queues.js:82:21) {
  ErrorMessage: 'read ECONNRESET',
  ErrorIdentifier: undefined,
  statusCode: null,
  response: null
}

[jona7o]

We are facing the exact same issue. We also use Firebase GCP Function from Frankfurt.

Sometimes we are able to call the function. I think there are some IPs blocked from the range? Overall it is a big problem, because just in the last hour more than 500 mails were not send out. Is there a solution?

Error: Unsuccessful: null read ECONNRESET
    at /workspace/node_modules/node-mailjet/mailjet-client.js:331:23
    at Request.callback (/workspace/node_modules/superagent/lib/node/index.js:905:3)
    at ClientRequest.<anonymous> (/workspace/node_modules/superagent/lib/node/index.js:822:12)
    at ClientRequest.emit (events.js:314:20)
    at ClientRequest.EventEmitter.emit (domain.js:483:12)
    at TLSSocket.socketErrorListener (_http_client.js:427:9)
    at TLSSocket.emit (events.js:314:20)
    at TLSSocket.EventEmitter.emit (domain.js:483:12)
    at emitErrorNT (internal/streams/destroy.js:92:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  ErrorMessage: 'read ECONNRESET',
  ErrorIdentifier: undefined,
  statusCode: null,
  response: null
} 

[danielluca]

Yes, that's exactly the same issue we are facing. Several mails are not send because of this. As far as we know today, Cloud Functions are using IP ranges and some of them are blocked by Mailjet.

Seems like the only solution is to use a static outbound IP address which should be used by the cloud function. We are still researching how we can provide our cloud functions with a static IP in GCP.

@jona7o

[jona7o]

@danielluca Unfortunately the mailjet support team can not help with this problem. Right now we are building a sendgrid fallback for the given error. If sendgrid works fine, we'll switch away the complete workload. I don't think it's getting solved in the near future. Hopefully we get a better customer service on paid plans. ;-)

[boldtrn]

@jona7o we switched to Sendgrid due to that issue about 3 weeks ago and haven't seen any issues anymore. We are also using GCP cloud functions from Frankfurt.

[danielluca]

Doesn't that cause problems with the GDPR? Maybe this is also an alternative for us 🤔

@boldtrn @jona7o

[danielluca]

For those who are interested, we are now using a static ip in our cloud functions. Did not solve every problem but it helped to reduce them a lot. We got this link from the firebase support which describes really well, how to setup and use static ip's: https://medium.com/@scorpion.nimit/how-to-create-a-firebase-cloud-function-with-static-outbound-ip-8086bbbdbbfe

[roger1345]

Hello! we are doing the same @danielluca. Using a vpc connector in our cloud functions to use an static ip address. So far we are not seeing any ECONRESET error (in the last 2 days). We are keeping an eye on the logs.

[danielluca]

@roger1345 👍 This approach fixed the issue for us. No more ECONNRESET Errors.

[ai-wintermute]

Hello @gdeichen, did you try to use a static IP address as suggested above? Did it solve your problem?

[gdeichen]

The server had a static IP. I ended up wiping it and starting from scratch. I haven't had the problem since.

[ai-wintermute]

@gdeichen thank you for the quick response. I'm closing the issue then.

[donalffons]

For those who are interested, we are now using a static ip in our cloud functions. Did not solve every problem but it helped to reduce them a lot. We got this link from the firebase support which describes really well, how to setup and use static ip's: https://medium.com/@scorpion.nimit/how-to-create-a-firebase-cloud-function-with-static-outbound-ip-8086bbbdbbfe

We encountered the same problem today and after several hours of research @danielluca's suggestion resolved the issue for us.

[afpatmin]

This just started happening to us seemingly out of nowhere (using firebase functions)

[AymericLegros]

Same here

[fj-vp]

For the past few weeks the same error occurs many times a day. The sdk runs on firebase function, running on the europe-west1 region.

[fbuland]

Same issue randomly since June 7th. No changes on my side. Using Node.js on AppEngine of Google Cloud Platform.

[zakton5]

Also getting this now, and also running on europe-west1.

[fbuland]

The issue is NOT from the library.

Maijet Support explanations :

Having in mind that you are using GCP, the issue most probably boils down to a blocked IP. The only reason why we would be blocking an IP address attempting to connect to our servers would be that too many unauthenticated requests were made from said IP via SMTP or HTTP. With a platform such as GCP, it is not unlikely that you have started being assigned IPs that had previously been used by other users on that platform, the actions of whom resulted in such unauthenticated calls.

Unfortunately, I can only check if a given IP is being blocked or not if I know its exact value (I cannot run this kind of check based on IP-ranges and on top of that, GCP utilizes hundreds of thousands of IPs, so checking each one is not a manageable task). I would recommend obtaining a TCP/IP capture in PCAP, that is recorded on the network level responsible for the request made to our server (as that way it would contain the public IP from which the call is being made)

[AngelaRT]

TL;DR We had the same issue and was solved by setting a Static IP.

Our app runs over GCP's App Engine. By default, Google assigns random IPs to the AppEngine services. Some of these random IPs are banned by Mailjet. When our services were assigned one of these banned IPs, Mailjet was responding with an ECONNRESET.

We followed this guideline and setup a Static IP. We had no more ECONNRESETs since then.

Note When setting up the Static IP we found some issues, as it was not working as expected. We found out that we had forgotten to create the Cloud NAT for all subnet IP ranges. This was making the VCP connector not reachable, and therefore the egress traffic was not able to get out. To solve it:

Instead of this:

gcloud compute routers nats create NAT_NAME \
    --router=ROUTER_NAME \
    --region=REGION \
    --nat-custom-subnet-ip-ranges=SUBNET_NAME \
    --nat-external-ip-pool=ORIGIN_IP_NAME

Do this:

gcloud compute routers nats create NAT_NAME \
    --router=ROUTER_NAME \
    --region=REGION \
    --nat-all-subnet-ip-ranges \
    --nat-external-ip-pool=ORIGIN_IP_NAME