Josh Klopfenstein

This is really neat! For the github action, should we use the well-supported [`docker/build-push-action`](https://github.com/docker/build-push-action/) instead? I think we can pretty much copy-paste the workflow [here](https://github.com/docker/build-push-action/#git-context). I feel that using dedicated...

It looks like [something like this](https://github.com/NethermindEth/juno/blob/a5adfc3b7e08ce1cd63702d73fe623925289046c/.github/workflows/docs-staging-tests.yml#L1) might have existed in the past?

[act](https://github.com/nektos/act#known-issues) looks like a good solution (thanks to @D-DePablos for pointing this out).

I have seen this as well. It may be because MDBX is writing the update to disk and needs to complete the transaction when we call `Close`. If this is...

Thanks! Forgot to initialize the logger on the metrics server. It should be working now.

That is by design. The logger is renamed [here](https://github.com/NethermindEth/juno/blob/7570c828cd88c0b1dfe5681039e1c56d3f0dc108/internal/sync/apiCollection.go#L41).

Hi! Something similar would make sense (struct with hi, lo uint64s). There is no need to implement receivers and methods we wouldn't use in Juno; adapter functions/receivers to convert to/from...

Very nice idea. > Implementing the logic in each rpc handler. We would only need to implement this in the websocket transport in the `jsonrpc` package, correct? No need to...

Yes. I was planning on doing this after #1389, but ended up focusing on other things in the meantime.

Noticed while working on this: we are using the [same namespace, subsystem, and name](https://github.com/NethermindEth/juno/blob/27c1ac20c794d8c7c95c71daa0669415b628669f/node/metrics.go#L78-L91) for all RPC method counters, across [all servers](https://github.com/NethermindEth/juno/blob/27c1ac20c794d8c7c95c71daa0669415b628669f/node/http.go#L80). Do we need to aggregate them somehow?