Dashboard/Backend/transactions: added mempool API/WS to fetch transactions from bitcoin node#72
Dashboard/Backend/transactions: added mempool API/WS to fetch transactions from bitcoin node#72sethdivyansh wants to merge 19 commits into
Conversation
97ce92d to
b785a7e
Compare
|
@Priceless-P Please review this when you get a chance. |
|
I noticed that it is missing
The rest of the endpoint seems okay. Let me know when you have them available so I can test them together. |
01decc0 to
71e6e88
Compare
| template: NewTemplate<'static>, | ||
| token: Vec<u8>, | ||
| tx_list_: Seq064K<'static, B016M<'static>>, | ||
| tx_list_receiver: Arc<tokio::sync::Mutex<TReceiver<Seq064K<'static, B016M<'static>>>>>, |
There was a problem hiding this comment.
Use roles_logic_sv2 Mutex not tokio Mutex
| } | ||
| super::IS_CUSTOM_JOB_SET.store(false, std::sync::atomic::Ordering::Release); | ||
|
|
||
| let tx_list_ = { |
There was a problem hiding this comment.
There should be a configurable duration (default of 30secs) to wait for a transactions to arrive. If no transaction arrives within that time, fall back to using the transaction from TemplateRx.
|
@Priceless-P I have made significant refactors in the transaction logic by switching from separate
It also reduced overall complexity. |
7e1b8ed to
a7b2fd4
Compare
| ); | ||
|
|
||
| if jd_event_broadcaster.send(template_notification).is_err() { | ||
| error!("Failed to send template notification: no receivers available"); |
There was a problem hiding this comment.
This will always fail because you are not using the receiver anywhere
There was a problem hiding this comment.
It will fail until a client is connected to the websocket.
Since this is a Tokio broadcast channel, receivers must explicitly subscribe to the sender in order to receive messages. That subscription happens inside the ws_event_handler() fn in jd_event_ws.rs.
Until at least one receiver is subscribed, any .send() call on the broadcaster will return an error which is expected behavior in this case.
| })); | ||
|
|
||
| // Set up the connection with the upstream for job response notifications | ||
| if let Err(e) = Upstream::set_job_declarator(&up, &self_) { |
There was a problem hiding this comment.
This connection setup is essential for enabling bidirectional communication between JobDeclarator and Upstream. Without it, Upstream can't notify JobDeclarator about job declaration responses, causing the API to wait indefinitely. By injecting a reference to JobDeclarator into Upstream, it enables a complete async response flow, ensuring the API receives timely feedback from the pool via Upstream.
|
Done with the changes. |
448d6ac to
739ec91
Compare
739ec91 to
894ac52
Compare
…nt to fetch transactions from the bitcoin node
… and confirmed transactions
…nt to fetch transactions from the bitcoin node
…nt to fetch transactions from the bitcoin node
b3098d2 to
8b5dcc1
Compare
Overview
This PR introduces a Rust-based backend service for streaming real-time Bitcoin blockchain data. Built with Axum, the service connects to a Bitcoin Core node via RPC and ZeroMQ to deliver blockchain events through WebSocket and REST API endpoints.
Add these lines to your
config.toml:Prerequisite::
To use ZMQ with Rust, the native ZeroMQ library (
libzmq) must be installed on the system. Thezmqcrate depends on it during compilation.Installation
API Endpoints
REST Endpoints
GET
/api/mempool- Current mempool transactions with full detailsWebSocket Endpoints
/ws/bitcoin/streamReal-time Bitcoin events (mempool + blocks)/ws/jd/streamReal-time NewTemplate event notificationsEvent Types
About zmq
The WebSocket stream provides four types of events:
A: New transactions added to mempool with full transaction detailsR: Transactions removed from mempool (includes txid and sequence number)C: New blocks mined with block hash and complete transaction listD: Block reorganizations with affected transactionsArchitecture
Error Handling