Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

handle developer errors from callbacks separate from fetch errors #87

Open
alexkli opened this issue Apr 26, 2022 · 4 comments
Open

handle developer errors from callbacks separate from fetch errors #87

alexkli opened this issue Apr 26, 2022 · 4 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@alexkli
Copy link
Contributor

alexkli commented Apr 26, 2022

Currently we share the same catch clause for fetch() and for the shouldRetry() here:

node-fetch-retry/index.js

Lines 217 to 227 in 3e512e5

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.

@tmathern
Copy link
Member

+1

@jdelbick
Copy link
Contributor

note: we pass in null for error here: shouldRetry(retryOptions, null, response, waitTime))
so retryOnHttpError will never get called in that case:

} else if (retryOptions && retryOptions.retryOnHttpError && error != null) {
// retryOnHttpError can be sync or async because either the promise or result will be
// bubbled up to what shouldRetry returns
return retryOptions.retryOnHttpError(error);

However, I agree we should separate these two functions so its more readable

@alexkli
Copy link
Contributor Author

alexkli commented Apr 26, 2022

@jdelbick but retryOptions.retryOnHttpResponse() will be called

@jdelbick
Copy link
Contributor

jdelbick commented Apr 26, 2022

@alexkli so you mean the situation if shouldRetry(retryOptions, null, response, waitTime) throws due to a developer error, then it goes to the next try/catch and could retry? makes sense, something like this:

try { 
     const response = await fetch(url, options); 
     try {
        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 (e) {
        // developer error
     }
 } catch (error) { 

edit, splitting out the try/catches & adding error handling, I get it

try { 
     const response = await fetch(url, options); 
} catch (e) {
  try {
     if (await shouldRetry(retryOptions, e, null, waitTime)) { ...
     }
  } catch (e) { //dev error}
}
try {
        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 (e) {
        // developer error
 }

@alexkli alexkli added this to the v3 milestone Apr 28, 2022
@alexkli alexkli self-assigned this Apr 28, 2022
@alexkli alexkli added the bug Something isn't working label Apr 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants