Exposed getblocktemplate rpc via REST endpoint.#230
Conversation
| } | ||
| } | ||
|
|
||
| fn getblocktemplate_rpc_error(err: &errors::Error) -> Option<(i64, String)> { |
There was a problem hiding this comment.
Codex review finding:
The Connection error handling here probably will not behave as intended.
Daemon::request() retries ErrorKind::Connection internally, so this REST error path is unlikely to see those errors.
For example, bitcoind warmup error -28 is converted into ErrorKind::Connection, which means /getblocktemplate would keep retrying instead of returning the intended 502 JSON response.
One related concern: Query::getblocktemplate() holds the block template cache mutex while making the daemon RPC call. If that RPC gets stuck retrying, later /getblocktemplate requests will block behind the same mutex.
There was a problem hiding this comment.
parse_jsonrpc_reply was changed to just return the error if getblocktemplate is called. The same behavior should prob be applied to submitpackage too but I didn't want to change that function too much in this PR. The infinite retry behavior is only desirable for internal calls to the daemon, not externally invoked ones.
There was a problem hiding this comment.
Overall looks pretty good. Currently I don't think that electrs directly proxies through any other calls to bitcoin node (although I was just considering it for calls to GET /block//raw... so electrs doesn't cache all the txs in the raw block).
We might also consider adding a startup flag (--enable-mining-rest) to enable this.
Randy808
force-pushed
the
add-getblocktemplate
branch
from
6f61218 to
a812004
Compare
|
Added the |
2 participants
No description provided.