cancel watches

[travisghansen]

With version 1.4.0 watch.watch returns a Promise that is the AbortController. When using a resourceVersion=X param (only retrieve updates from the current state) the Promise appears to only resolve after the first update has been received.

In my case I am trying to do some crude dead peer/watch detection and this pattern has some challenges. Let's say I have a 10m inactivity window where I consider the peer/watch dead if no messages have been received in that window. If nothing comes through in the 10m window I still have an unresolved Promise and therefore cannot call AbortController.abort() to abort the request. If I can't abort the request and just recreate a new watch I possibly end up with multiple active watches.

Any thoughts or other ideas about how to sanely check for dead peer/watches and/or how to deal with the AbortController not being available until the first message has been received?

Thanks!

[travisghansen]

I will note this behavior seems to be different than what it was in the pre 1.0 days where request was still being used.

[brendandburns]

My guess is that this is not actually related to the resource version parameter exactly, I suspect that it hangs waiting for some output regardless, it's just without the resourceVersion there's always some data to return.

I think we'd be open to refactoring the code to return the promise earlier if it is feasible.

[travisghansen]

Yeah that makes sense. I would appreciate updated logic!