Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Websocket stalls consistently #47

Open
hut8 opened this issue Feb 2, 2024 · 1 comment
Open

Websocket stalls consistently #47

hut8 opened this issue Feb 2, 2024 · 1 comment

Comments

@hut8
Copy link

hut8 commented Feb 2, 2024

Hey there. Thanks for making such an awesome library. I'll be happy to help resolve this but would like some input regarding how you would like it to be handled.

It seems like pretty consistently, after subscribing to the ticker on the Websocket v2 API (for starters, I'm just using "BTC/USD" and "ETH/USD"), I will get data for several hours hours then it will suddenly stop. I practically copied and pasted your example from the docs as a starting point:

pub async fn subscribe(db: &DatabaseConnection, symbols: Vec<String>) -> anyhow::Result<()> {
    let mut client = kraken_ws_client::connect_public()
        .await
        .expect("cannot connect");

    let req = if symbols.is_empty() {
        SubscribeTickerRequest::all()
    } else {
        SubscribeTickerRequest::new(symbols)
    };

    client.send(req).await.expect("cannot send request");

    while let Some(event) = client.ticker_events().next().await {
        for ticker_data in event.data.iter() {
          // fine for some hours
       }
   }

   // Code does not reach here after the stall
   Ok(())
}

So it gets stuck in the ticker events loop. After it stalled, it held the websocket open for seemingly forever (I killed it at least 8 hours later manually). One time it stalled after 2 hours, currently it's been running at 4 with no issues but I'm pretty sure it will stall at some point. Is this something you've run into? Do you have an easy workaround?

@gmosx
Copy link
Owner

gmosx commented Feb 14, 2024

Thanks for the report.

We could add a mechanism to check the heartbeat messages, and if they don't arrive for e.g. 10s, it should trigger a re-connection. That would make the client more robust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants