Retry middleware does not handle other side closing unexpectedly about wretch HOT 4 CLOSED

Thank you so much! That seems to work fine for me as well!

from wretch.

Hi @mitom,

I'm not entirely sure if it's a bug or if I'm doing something wrong, but hope you can help me out.

I don't think you are doing anything wrong, it is caused by a limitation of the retry middleware that only checks the initial response from the server (status 200) to determine whether it should retry the request or not.

In this particular case the error is thrown by the .blob() method which happens later on when downloading the body.

from wretch.

Thank you @elbywan, that makes sense. Do you have any suggestion on how to approach this?

What I can think of is to catch the error outside of wretch and trigger a new request through a new wretch instance until it completes (or whatever other condition is met). The downside of this is that it kinda makes the retry middleware almost harmful for me since the number of actual retries I could make is retry middleware config * my external error catching, and it's kinda difficult to adjust the combination of the both.

I've looked into the addons, but from what I understand they don't really cater to this and I'm not sure it's possible to handle an error in them when it's in the body itself. (Although, my confidence in this statemenet being accurate is low, so feel free to correct me.)

I think a middleware may be able to do this but I'm not sure if this is intended for them (i.e. docs say Middlewares are functions that can intercept requests before being processed by Fetch - that reads to me like they're not mean to deal with this scenario).

Is the best path to wrap the error handling around wretch, drop the retry addon and just create new wretch instances or is there something in wretch that I can use to handle these nicer?

from wretch.

Is the best path to wrap the error handling around wretch, drop the retry addon and just create new wretch instances or is there something in wretch that I can use to handle these nicer?

I had another look at the problem this morning and I came up with a pretty concise way of doing this by tweaking the retry middleware a bit (by adding an until argument):

import wretch from 'wretch'
import { retry } from "wretch/middlewares"
import ProgressAddon from "wretch/addons/progress"

async function main() {
  return wretch("http://localhost:3002")
    .addon(ProgressAddon())
    .middlewares([retry({
      retryOnNetworkError: true,
      until: async (response, error) => {
        if (!response?.ok || error) {
          // Response status !== 2xx or network error = retry
          return false
        }
        try {
          // Clone the body and buffer it ahead of time…
          const reader = response.clone().body.getReader();
          await (async function process({ done, value }) {
            if (done) return;
            return process(await reader.read());
          })(await reader.read());
          // No issue while reading the body = don't retry
          return true
        } catch (readError) {
          // Error while reading the body = retry
          return false
        }
      }
    })])
    .get()
    .progress((loaded, total) => {
      console.log(`progress ${(loaded / total * 100).toFixed(0)}%`)
    })
    .blob()
    .then(blob => console.log("blob size", blob.size))
    .catch(error => console.log("error", error))
}

await main()

I tested with node@20 (21.x implementation seems bugged and panics) and I could see the requests being retried when the connection gets closed, let me know it this works for you 🤞 .

from wretch.