fix: retry Filecoin.StateMinerInfo requests

[bajtos]

• deps: add retry from Deno stdlib
• fix: retry Filecoin.StateMinerInfo requests

I noticed that sometimes my Station Desktop will go offline. The module logs contain the following messages:

[2024-09-23T12:43:03Z INFO  module:spark/main] Calling Filecoin JSON-RPC to get PeerId of miner f02085652
{"type":"activity:error","module":"spark/main","message":"SPARK failed reporting retrieval"}
[2024-09-23T12:43:04Z ERROR module:spark/main] Error: Cannot obtain miner info for f02085652: error sending request for url (https://api.node.glif.io/): connection closed before message completed
        at async mainFetch (ext:deno_fetch/26_fetch.js:277:12)
        at async fetch (ext:deno_fetch/26_fetch.js:504:7)
        at async rpc (file:///Users/bajtos/Library/Caches/app.filstation.desktop/sources/spark/lib/miner-info.js:36:15)
        at async Spark.getMinerPeerId (file:///Users/bajtos/Library/Caches/app.filstation.desktop/sources/spark/lib/miner-info.js:9:17)
        at async Spark.executeRetrievalCheck (file:///Users/bajtos/Library/Caches/app.filstation.desktop/sources/spark/lib/spark.js:50:22)
        at async Spark.nextRetrieval (file:///Users/bajtos/Library/Caches/app.filstation.desktop/sources/spark/lib/spark.js:197:5)
        at async Spark.run (file:///Users/bajtos/Library/Caches/app.filstation.desktop/sources/spark/lib/spark.js:208:9)
        at async file:///Users/bajtos/Library/Caches/app.filstation.desktop/sources/spark/main.js:4:1
[2024-09-23T12:43:04Z INFO  module:spark/main] Sleeping for 75 seconds before starting the next task...

In other words, when the RPC API fails, Spark waits more than a minute until it starts another check. I think that next check will pick the next task from the list, meaning that Spark effectively skips a task when this error happens.

In this pull request, I am wrapping the RPC request in a retry logic.

[juliangruber]

nice!

[bajtos]

A test was failing, so I had to tweak this change. PTAL again.

[juliangruber]

Why not keep err with err.cause?

[bajtos]

I feel the caller of this function does not care that we are retrying the requests; they are interested in the details about why the request failed.

[juliangruber]

Good point!