Error: getaddrinfo ENOTFOUNDL api.cloudinary.com api.cloudinary.com:443
ERROR: { Error: getaddrinfo ENOTFOUND api.cloudinary.com api.cloudinary.com:443
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)
errno: 'ENOTFOUND',
code: 'ENOTFOUND',
syscall: 'getaddrinfo',
hostname: 'api.cloudinary.com',
host: 'api.cloudinary.com',
port: 443 }
[2019-09-03T14:38:15.067Z] ERROR: nexus/12255 on DESKTOP-7RIOOGT:
Image upload error { Error: getaddrinfo ENOTFOUND api.cloudinary.com api.cloudinary.com:443
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)
errno: 'ENOTFOUND',
code: 'ENOTFOUND',
syscall: 'getaddrinfo',
hostname: 'api.cloudinary.com',
host: 'api.cloudinary.com',
port: 443 }
Above is the error output. I am not sure what is happening as this worked as of Thursday this past week. I am guessing it may be on your end of things? Any help is appreciated. We are using v2.uploader.upload_stream and of 47 files 46 upload consistently, sometimes all 47. Below is the code.
const cloudinaryUp = ({ files }, directory) =>
Promise.all(files.map(file => new Promise((resolve, reject) => {
const { buffer, stream } = file
const { base, suffix } = getFilenameData(file)
const uploadStream = cloudinary.v2.uploader.upload_stream(
{
folder: directory,
public_id: base,
},
(error, result) => {
log.info('Uploaded new file:', result)
if (error) {
console.log('ERROR: ', error)
reject(error)
} else {
// Resolve with the file name, sans the prefix, since we don't store
// it in the database
resolve({ fileName: `${base}${suffix}` })
}
},
)
if (buffer) {
uploadStream.end(file.buffer)
} else if (stream) {
stream.pipe(uploadStream)
}
})))-
Has this been repaired in any way? I can no longer reproduce the issue but as of yesterday 10/14/2019 I was seeing the same issue at random intervals of testing my batch file upload. It seems to be uploading much more quickly today and without the inconsistent ENOTFOUND error. Any feedback into this would be appreciated!
DRC
-
Hi both,
First regarding @DSC Unailag -
I saw that you also reported this issue through a Zendesk ticket which I've just responded on, but I'll include the details here in case any other users of Firebase come across this.
The likely cause of this (if you're using the Spark plan) is the restriction that Google specifies when using Firebase Cloud functions and calling external services/APIs. Specifically, I would suggest checking the functions logs in the console as there could be a warning similar to;
"Billing account not configured. External network is not accessible and quotas are severely limited. Configure billing account to remove these restrictions"I've also found a few related StackOverflow questions for other users that experienced similar issues when calling services outside of Google.
https://stackoverflow.com/questions/42784135/cloud-functions-for-firebase-billing-account-not-configured
https://stackoverflow.com/questions/43244509/cloud-functions-for-firebase-getting-network-error-even-though-im-making-outb
In addition, you can also find this restriction listed under the pricing section for the Spark plan:
https://firebase.google.com/pricing. Outbound networking within Cloud functions is set to "Google services only".Is it the case that you're on the Spark plan?
@David - May I please ask for some additional information regarding your environment, specifically; where is your app hosted? In addition, next time you encounter this issue, could you please run the following two commands from your server and share the output:dig api.cloudinary.com
dig @8.8.8.8 api.cloudinary.com
Thanks,
Aleksandar -
Aleksandar,
The app is currently in development and running locally on a development server. There are times when the upload is successful but most often is has been failing.
dig api.cloudinary.com
; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> api.cloudinary.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59166
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;api.cloudinary.com. IN A;; ANSWER SECTION:
api.cloudinary.com. 41 IN A 34.203.83.223
api.cloudinary.com. 41 IN A 52.4.255.133
api.cloudinary.com. 41 IN A 3.219.230.135
api.cloudinary.com. 41 IN A 52.205.231.180;; Query time: 38 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Oct 16 15:12:21 EDT 2019
;; MSG SIZE rcvd: 111dig @8.8.8.8 api.cloudinary.com
; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> @8.8.8.8 api.cloudinary.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16987
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;api.cloudinary.com. IN A;; ANSWER SECTION:
api.cloudinary.com. 3 IN A 34.203.83.223
api.cloudinary.com. 3 IN A 52.4.255.133
api.cloudinary.com. 3 IN A 52.205.231.180
api.cloudinary.com. 3 IN A 3.219.230.135;; Query time: 58 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Oct 16 15:12:41 EDT 2019
;; MSG SIZE rcvd: 111 -
Thanks for providing this David.
It seems that the DNS entries you're getting are correct in your current example. Is that the case if you run those commands during a time you're seeing upload issues?
Also, are there any proxies or similar between your system and Cloudinary's that might rely on a different DNS server or perhaps any local etc/hosts file configurations that might affect this?
In addition, are your uploads done from a single server or distributed, are you seeing similar errors or percentage of failures across the servers?
Looking forward to your response.
Best regards,
Aleksandar
Post is closed for comments.
Comments
7 comments