Currently we share the same catch clause for fetch() and for the shouldRetry() here:
|
try { |
|
const response = await fetch(url, options); |
|
|
|
if (await shouldRetry(retryOptions, null, response, waitTime)) { |
|
console.error(`Retrying in ${waitTime} milliseconds, attempt ${attempt} failed (status ${response.status}): ${response.statusText}`); |
|
} else { |
|
// response.timeout should reflect the actual timeout |
|
response.timeout = retryOptions.socketTimeout; |
|
return resolve(response); |
|
} |
|
} catch (error) { |
shouldRetry includes calling the callbacks retryOnHttpError() and retryOnHttpResponse(). These callbacks could have developer errors on which we should not retry blindly.
Instead, we should separate the error handling, and for errors on the callbacks pass them through as clear errors (and do not retry) so the developers can fix their code.
Currently we share the same catch clause for
fetch()and for theshouldRetry()here:node-fetch-retry/index.js
Lines 217 to 227 in 3e512e5
shouldRetry includes calling the callbacks
retryOnHttpError()andretryOnHttpResponse(). These callbacks could have developer errors on which we should not retry blindly.Instead, we should separate the error handling, and for errors on the callbacks pass them through as clear errors (and do not retry) so the developers can fix their code.