feat: add WsServer handle

[mattsse]

Motivation

provide a way to retrieve the spawned WsServer on error

Solution

Add WsServerHandle type that wraps the JoinHandle for the spawned WsServer.

WsServer -> into_future -> WsServerFuture -> spawn -> WsServerHandle -> await -> Err(WsServer)

the WsServerFuture::Output will be WsServer in the error case

I don't think there's an easy way to make this work in wasm since the future would need to return JsValue for it to be wrapped in a promise, so I think it's fine to exclude this for wasm

todo

• store requests along with their id
• provide reconnect function

the output type of the handle is a bit verbose but could be used like

  let (ws, handle) = Ws::new_pair(...);
  
  tokio::task::spawn(async move || {
        let mut handle = handle;
        loop  {
           if let Err((ws,_)) handle.await.unwrap() {
               handle = ws.reconnect().await.unwrap();
           }
       }

})

cc @prestwich

PR Checklist

• Added Tests
• Added Documentation
• Updated the changelog

[gakonst]

can we not make the reconnect logic always trigger after constructing the websocket?

[mattsse]

I think this should be configurable because you might want to set something like: how many reconnects, perhaps alternative endpoint

but maybe we should configure reconnect as default

[gakonst]

what should we do here?

[mattsse]

sorry forgot about this.

was kinda hoping someone else would pick this up.

should we keep this open so someone can take over/use this as inspiration?

I feel like this is not a high priority at this time.

[gakonst]

OK closing then and let's have someone else pick it up if they feel like it.

[0xMelkor]

Hi guys,

How about propagating the Ws handle at the application layer?

We could make it accessible from the Provider<Ws> instance. Handling reconnection logic under the hood might not be a good solution (snapview/tokio-tungstenite#101)

[prestwich]

Handling reconnection logic under the hood might not be a good solution (snapview/tokio-tungstenite#101)

I think it's safe to assume that all ethers users want automatic reconnection (without an explicit instruction from the user to disconnect)

[0xMelkor]

I think it's safe to assume that all ethers users want automatic reconnection (without an explicit instruction from the user to disconnect)

You are right, but maybe the solution lies in the middle. A retry mechanism could be implemented at the transport layer; whenever the situation becomes unrecoverable, the application should take control and issue specific actions.

[georgewhewell]

Handling reconnection logic under the hood might not be a good solution (snapview/tokio-tungstenite#101)

I think it's safe to assume that all ethers users want automatic reconnection (without an explicit instruction from the user to disconnect)

fwiw i (ethers user) don't want automatic reconnect. reconnect may take a long time/fail and its possible endpoint may be misbehaving in other ways, i would prefer to handle errors myself and restart relevant parts of my app from known-good state

[0xMelkor]

Picking this up

[0xMelkor]

Opened #1915