-
Notifications
You must be signed in to change notification settings - Fork 795
Conversation
…nect. the Websocket.
Lint cargo +nightly fmt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imo, it makes more sense to handle this gracefully and don't panic on the ws task.
needs changelog entry
- Added `#` prefix to issue IDs where missing
Hi @mattsse, changelog updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the dumb question, but how can I catch this panic or error, i mean is there place to match it. I don't get messages from websocket often and it breaks with connection refused. Now I took one of the solutions with 2 loops and a timeout in tokio select! like there #1889 . |
Hi @Tigranchick, this PR removed the // This loop iterates over WebSocket disconnections
'connection: loop {
let client = Provider::<Ws>::connect("wss://your-uri").await?;
let client = Arc::new(client);
let filter = Filter::new().event("Transfer(address,address,uint256)");
let mut stream = client.subscribe_logs(&filter).await?;
while let Some(log) = stream.next().await {
// Do some work
}
// If you get here, your subscription has been canceled => Iterate over the main loop to handle reconnection
} How can we improve ethers in my opinionA cleaner approach would also propagate errors from Ws to the application. // The stream now emits `Result`instead of `Log`
while let Some(result) = stream.next().await {
match result {
Ok(log) => // Do some work
Err(e) => // Handle the error
}
} |
@0xMelkor, thanks you to explanation! |
Motivation
Some issues have been raised, reporting
WsServer
panics on upstream connection errors.#1889 #1815
ethers-rs/ethers-providers/src/transports/ws.rs
Lines 250 to 256 in 4b68562
Solution
In order to have a simpler and more predictable behavior, I believe the application should directly handle reconnections (also stated here), avoiding recovery mechanisms at the transport layer.
Instead of crashing the program, we gracefully close all active subscriptions. Clients will then observe the end of their streams and issue proper actions.
What do you guys think?
PR Checklist