You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
milesnash opened this issue
Jul 14, 2022
· 0 comments
· Fixed by #1294
Labels
priority: p2Moderately-important priority. Fix may not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.
This issue is closely related to #1203 in terms of how it manifests for consumers of client libs that in turn use this lib for making requests. However, its source is in a close-but-separate area of the code.
Consider the following code:
import{DisksClient}from'@google-cloud/compute';constclient=newDisksClient();constproject='my-project';constzone='us-east1';try{const[disks]=awaitclient.list({
project,
zone
});}catch(err){console.error(err);}
I expected to land in the catch block in the case of transient network errors such as ETIMEDOUT. However, my program still errors with the following:
{
"errorType": "Runtime.UnhandledPromiseRejection",
"errorMessage": "FetchError: request to https://compute.googleapis.com:443/compute/v1/projects/my-project/regions/us-east1/disks? failed, reason: connect ETIMEDOUT [REDACTED IP ADDR]:443",
"reason": {
"errorType": "FetchError",
"errorMessage": "request to https://compute.googleapis.com:443/compute/v1/projects/my-project/regions/us-east1/disks? failed, reason: connect ETIMEDOUT [REDACTED IP ADDR]:443",
"code": "ETIMEDOUT",
"message": "request to https://compute.googleapis.com:443/compute/v1/projects/my-project/regions/us-east1/disks? failed, reason: connect ETIMEDOUT [REDACTED IP ADDR]:443",
"type": "system",
"errno": "ETIMEDOUT",
"stack": [
"FetchError: request to https://compute.googleapis.com:443/compute/v1/projects/my-project/regions/us-east1/disks? failed, reason: connect ETIMEDOUT [REDACTED IP ADDR]:443",
" at ClientRequest.<anonymous> (/var/task/node_modules/node-fetch/lib/index.js:1461:11)",
" 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)"
]
},
"promise": {},
"stack": [
"Runtime.UnhandledPromiseRejection: FetchError: request to https://compute.googleapis.com:443/compute/v1/projects/my-project/regions/us-east1/disks? failed, reason: connect ETIMEDOUT [REDACTED IP ADDR]:443",
" at process.<anonymous> (/var/runtime/index.js:35:15)",
" at process.emit (events.js:400:28)",
" at process.emit (/var/task/src/functions/runner/exec/handler.js:623206:21)",
" at processPromiseRejections (internal/process/promises.js:245:33)",
" at processTicksAndRejections (internal/process/task_queues.js:96:32)"
]
}
The fetch error message in this example is generated in node-fetch here. The fetch() Web API would also reject in such circumstances as described here.
I believe that consumers of such client libs would want to handle these errors in the way I have shown above and as described in #1203.
The text was updated successfully, but these errors were encountered:
milesnash
added
priority: p2
Moderately-important priority. Fix may not be included in next release.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
labels
Jul 14, 2022
priority: p2Moderately-important priority. Fix may not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.
This issue is closely related to #1203 in terms of how it manifests for consumers of client libs that in turn use this lib for making requests. However, its source is in a close-but-separate area of the code.
Consider the following code:
I expected to land in the catch block in the case of transient network errors such as ETIMEDOUT. However, my program still errors with the following:
The fetch error message in this example is generated in node-fetch here. The fetch() Web API would also reject in such circumstances as described here.
I believe that consumers of such client libs would want to handle these errors in the way I have shown above and as described in #1203.
The text was updated successfully, but these errors were encountered: