Skip to content
This repository has been archived by the owner on Oct 19, 2024. It is now read-only.

WS Provider Panic - reason: "upstream went away" #1815

Open
Tiergarten opened this issue Oct 28, 2022 · 3 comments
Open

WS Provider Panic - reason: "upstream went away" #1815

Tiergarten opened this issue Oct 28, 2022 · 3 comments
Labels
bug Something isn't working

Comments

@Tiergarten
Copy link

Tiergarten commented Oct 28, 2022

I am occasionally hitting the below panic in ethers-providers/src/transports/ws.rs impl WsServer

The error message I get is "upstream went away", I believe this is a network / reliability issue with my json-rpc provider however I would like to catch it and restart the listening thread - this panic is making that difficult.

Are there any recommendations on how to proceed?

    /// Spawns the event loop
    fn spawn(mut self)
    where
        S: 'static,
    {
        let f = async move {
            loop {
                if self.is_done() {
                    debug!("work complete");
                    break
                }
                match self.tick().await {
                    Err(ClientError::UnexpectedClose) => {
                        error!("{}", ClientError::UnexpectedClose);
                        break
                    }
                    Err(e) => {
                        panic!("WS Server panic: {}", e);
                    }
                    _ => {}
                }
            }
        };

Thanks,
Matt

@Tiergarten Tiergarten added the bug Something isn't working label Oct 28, 2022
@cliff0412
Copy link

same issue here.
i am getting below error, but do not know how to capture and handle
2022-11-15T16:42:32.333490Z DEBUG tungstenite::protocol: Received close frame: Some(CloseFrame { code: Away, reason: "upstream went away" })
2022-11-15T16:42:32.334704Z DEBUG tungstenite::protocol: Replying to close with Frame { header: FrameHeader { is_final: true, rsv1: false, rsv2: false, rsv3: false, opcode: Control(Close), mask: None }, payload: [3, 233, 117, 112, 115, 116, 114, 101, 97, 109, 32, 119, 101, 110, 116, 32, 97, 119, 97, 121] }

@Tiergarten Tiergarten changed the title WS Provider Panic WS Provider Panic - reason: "upstream went away" Nov 16, 2022
@0xMelkor
Copy link
Contributor

0xMelkor commented Nov 25, 2022

Hi guys,
As you can see the library needs more robust handling of Websocket errors.
At the moment there is a pull request that is trying to fix this: 1675.

@ibhagwan
Copy link

Getting a similar issue (for a different ws error):

2022-11-30 13:31:40.488 DEBG Received close frame: Some(CloseFrame { code: Away, reason: "CloudFlare WebSocket proxy restarting" })
2022-11-30 13:31:40.488 DEBG Replying to close with Frame { header: FrameHeader { is_final: true, rsv1: false, rsv2: false, rsv3: false, opcode: Control(Close), mask: None }, payload: [3, 233, 67, 108, 111, 117, 100, 70, 108, 97, 114, 101, 32, 87, 101, 98, 83, 111, 99, 107, 101, 116, 32, 112, 114, 111, 120, 121, 32, 114, 101, 115, 116, 97, 114, 116, 105, 110, 103] }
thread 'tokio-runtime-worker' panicked at 'WS Server panic: Websocket closed with info: CloseFrame { code: Away, reason: "CloudFlare WebSocket proxy restarting" }', /home/bhagwan/.cargo/registry/src/github.com-1ecc6299db9ec823/ethers-providers-1.0.2/src/transports/ws.rs:255:25

Seems to be panicing at the same spot as OP describes:

match self.tick().await {
Err(ClientError::UnexpectedClose) => {
error!("{}", ClientError::UnexpectedClose);
break
}
Err(e) => {
panic!("WS Server panic: {}", e);
}
_ => {}
}

Would love to have a solution as mentioned in #1675 so I can gracefully handle the reconnect,

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants