Implement a retry policy when calling the netlify API

[meziantou]

Is your feature request related to a problem? Please describe.

When deploying a site using the CLI (netlify deploy), I got the following error:

Deploy path: /home/vsts/work/1/netlify/netlify
Deploying to main site URL...
- Hashing files...
✔ Finished hashing 3953 files
- CDN diffing files...
✔ CDN requesting 31 files
- Uploading 31 files
✔ Finished uploading 31 assets
- Waiting for deploy to go live...
 ›   Warning: 
 ›   {
 ›     "message": "request to https://api.netlify.com/api/v1/sites/xxx
 ›   xxx/deploys/xxx failed, reason: 
 ›   Client network socket disconnected before secure TLS connection was 
 ›   established",
 ›     "type": "system",
 ›     "errno": "ECONNRESET",
 ›     "code": "ECONNRESET",
 ›     "name": "FetchError",
 ›     "url": "https://api.netlify.com/api/v1/sites/xxx/deploys/xxx",
 ›     "data": {
 ›       "method": "GET",
 ›       "headers": {
 ›         "User-agent": "netlify/js-client",
 ›         "accept": "application/json",
 ›         "Authorization": "Bearer ***"
 ›       }
 ›     }

FetchError: request to https://api.netlify.com/api/v1/sites/xxx/deploys/xxx failed, reason: 
    Client network socket disconnected before secure TLS connection was 
    established
    Code: ECONNRESET

Describe the solution you'd like

I think the client should retry the call when this looks like a transient error, and actually raise an error only after a few attempts.

Describe alternatives you've considered

Handling the exit code and retry manually. However, this would re-execute the previous steps (hashing + uploading), so not great.

Can you submit a pull request?

No.

[erezrokah]

Thanks @meziantou, adding some context to this - it should be implemented in the js-client: https://github.com/netlify/js-client/blob/960089a289288233bd2a17fcbd8ab4730ca49135/src/deploy/index.js#L101 or be a part of https://github.com/netlify/js-client/issues/157

[meziantou]

The links seems specific to the deploy command. I think this behavior should be implemented for any http calls as long as it is a transient error.

[erezrokah]

think this behavior should be implemented for any http calls as long as it is a transient error.

Do you mind updating the title of the issue to reflect that?