-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
Extending the timeout #26
Comments
Hi @drmrbrewer that is defiantly an interesting use-case. Without understanding more about how your code is set up, it's hard to really say if it's a bad thing to do ;) The idea is interesting enough I thought maybe to just add it, but since this module uses a |
Thanks for considering. It would even be useful just to cancel the existing |
haha, I thought of that solution as well, and oops, forgot to mention it above. Yea, that is a good solution; I'll definitely work to implement, but not 100% sure if it'll be today, so please feel free to work on that implementation :) AFAIK, |
@dougwilson any update on that? If |
I did a tiny bit of work on this a while back, but I think there was some complications and I shelved the work and forgot about it. |
This would help me out as well. I created PR #34 that adds 3 methods.
|
See |
So far as I understand it, the timeout value is set when you add the
connect-timeout
middleware when initializing the express server, so the same timeout applies to every request the comes in thereafter (that matches the route concerned).What I'm finding is that for some incoming GET requests, there is a particular combination of options in the request that causes a network fetch to a remote resource than is not very reliable. For those requests, I'd like to relax the timeout value for
connect-timeout
somewhat, to allow for a few fetch retries.But I can't see any way to change the timeout value 'on the fly', for a particular request. The only control I can see over the timeout is to use
req.clearTimeout()
whilst processing a request. This is helpful, buttimeout is completely removed and will not fire for this request in the future
. This is not entirely what I'm looking to achieve... I would like to retain a timeout, but just a slightly longer one.Is what I'm asking for really naughty, breaking established rules of good practice of which I'm not aware? Or is it a reasonable thing to want to do?
The text was updated successfully, but these errors were encountered: