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

Bug: blockchain.headers.subscribe and blockchain.scripthash.subscribe method not work #131

Open
eauxxs opened this issue Apr 10, 2024 · 0 comments

Comments

@eauxxs
Copy link

eauxxs commented Apr 10, 2024

use electrum_client::{Client, ElectrumApi};

fn main() {
    let client = electrum_client::raw_client::RawClient::new(("blockstream.info", 143), None).unwrap();

    let r = client.block_headers_subscribe().unwrap();
    // print, but just once
    dbg!(r);  
    loop {
        std::thread::sleep(std::time::Duration::from_secs(5));
        let x = client.block_headers_pop().unwrap();
        // always is None
        dbg!(x);  
    }
}

client.block_headers_pop() is always None.

All clinet's jsonrpc calls use the self.call method. The self.call method constructs a request containing the id, and uses self.recv to wait for the result of the corresponding id. In self.recv, use self._reader_thread to wait for the result of this id, and then exit, ignoring the subsequent results of the subscription method.
Since this is a synchronous library, I looked for some trace of std::thead::spawn in the code, but couldn't find it.

  1. Is my calling method wrong? This is a library that has been around for a long time. I think this is the reason. If yes, is it possible to add example code? This problem is really a headache.
  2. When calling the subscription method, can a channel be returned instead of putting all the results into a VecDeque, which still requires the user to constantly check whether there is new data?
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

1 participant