Closed realeinherjar closed 10 months ago
Thanks for the feedback. It is helpful. I will try to modify the approach. 👍🏻
Aproach NACK
Thank you for taking a shot at this.
Why 500ms? What if the server expects us to wait for 600ms? I would prefer if we checked the
Retry-After
header. If that does not exist, then have an exponential back-off delay as a fallback.Do we need the async recursion? Is there a way to do it with a loop?
I also think introducing
tokio
as an async dependency is a big ask. Would it be trivial to implement a simpleFuture
usingInstant
?
Not really trivial and using std::time::Instant
breaks WASM probably. We'd need to do some work to have the timer work on WASM: See: https://github.com/whizsid/wasmtimer-rs
I would avoid sleeping and just lower the number of batch requests in the next round by the number of 429s you get.
PS are we testing this crate on WASM? If not PR fixing that before this one would be good.
I will try another approach in the bdk_esplora
crate and not here.
EDIT:
More specifically, 429s could be handled inside this loop
that calls scripthash_txs
:
Closes https://github.com/bitcoindevkit/bdk/issues/1120
Details
BlockingClient
:scripthash_txs
for 429 Status codes. If detected, hard-coded sleep for 500ms usingstd::thread::sleep
(so it is also thread-safe).AsyncClient
(little more convoluted thanBlockingClient
):tokio
andasync-recursion
into thedependencies
.scripthash_txs
we are checking for 429 Status codes. If detected, hard-coded sleep for 500ms usingtokio::time::sleep
. Since this is an "async recursion" the macroasync_recursion
handles that gracefully without having to deal with:If we annotate the offending recursive function with
#[async_recursion]
, it automatically convert an async function to one returning a boxedFuture
.