Extending the timeout about timeout

[dougwilson]

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, req.setTimeout method already exists, so will probably need to refactor some stuff not to shadow that method.

[dougwilson]

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 setTimeout object under the hood, that object does not provide any way to ether (a) extend the timeout or (b) get the elapsed time it has seen, which certainly would make implement this difficult.

[drmrbrewer]

Thanks for considering. It would even be useful just to cancel the existing setTimeout() (which is I assume what is presently possible via req.clearTimeout()) and re-start a new setTimeout() using a different timeout value to the one used originally. That way, when a new request comes in that I know will need a little more time, I can (before I've started really processing the request) just set up a new (longer) timeout.

[rohithkd]

@dougwilson any update on that? If connect-timeout can override the default behavior, it would be very helpful.

[dougwilson]

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.

[UziTech]

This would help me out as well. I created PR #34 that adds 3 methods.

req.setTimeout(delay): reset the timeout and start from now
req.addTimeout(delay): add to the current timeout
req.timeoutLeft(): get the amount of milliseconds left (0 after timedout)

[JamesMGreene]

See express-timeout-handler alternative implementation with the ability to override the timeout. 👍🏻