Perpetually attempts reconnecting on socket error about undici HOT 10 CLOSED

I think we should improve the API with a few caveats:

1. a max number of retries for reconnects that will emit an error on the client itself, so we can potentially let the application do something.
2. an offline event, so that the app can do something
3. make the requests error after a timeout

from undici.

Thanks for your efforts! I know these problems are hard and those kind of bugs elusive. If you’d still come and take a shot after some time, you are always welcomed!

from undici.

I think we could look at https://www.npmjs.com/package/reconnect-core for some inspiration.

from undici.

Well, I suppose the above is imprecise. While it does attempt to reconnect that isn't the heart of the issue. Rather, at the time it attempts to reconnect there are 0 callbacks in the queue for the client. Which leads to the lack of notification.

Still digging, but wanted to course correct the above line of thinking about what the core problem is.

from undici.

If you find the root cause, please send a PR!

from undici.

Got it, gonna do a quick PR and see if there any design tweaks needed with it. Thanks

from undici.

Okay, PR #12 is sent. As noted I went for what I thought would have the lowest chance of unintended consequences. That said it does feel slightly hacky. If you have thoughts on a better way to approach it I'd be glad to tackle it. Thanks

Sorry for all the noise. I'm going to work on a better solution that I feel confident doing a PR on.

from undici.

Those sound like nice enhancements that would definitely address my needs. I can take a stab at those over the next few days and see if I can come up with clean implementations of each.

from undici.

Unfortunately I haven't been successful tackling the proposed API updates. I did add a maxRetries option in this branch. However, the tricky part is that if a client is initialized against a non-listening URL it will never be placed in kQueue, as it will just hang in the reconnect process until maxRetries (if set) is hit.

That being the case the callback never gets into the queue and so all affected requests will remain hung even after we emit maxRetries and close the client.

Similarly, in that scenario it will never make it to the timer in order to execute the timeout error on the request. I've tried several methods of working around this, mostly by changing the order of operations around. For instance moving the if (!this.socket) connect(...) into the kQueue worker function, but this leads to other requests hanging indefinitely.

Similarly I've tried initializing the Request, wrapping the callback, and placing it in the queue before the call to connect but that has led to various other issues.

I'm sure there is a way to do this, but unfortunately I've put a good bit of time toward trying and have failed at every turn. I'm not sure if you might want to keep this issue open for any reason, so I'll leave it open for now but feel free to close it.

from undici.

I've seen this as well, it goes into a live lock loop of reconnecting.

from undici.