Move error handling and back-off to a separate process (for now)

I am doing this in branch feat/proc. I will run this on my instance for a few days before merging.

My new approach here is to NOT to try and find point in the dro code where we end up making an HTTP request that can fail (either because the network connection is unreliable or because Cloudflare throws a 50x or because Alchemy throws a 50x or even a 40x). Instead, I'm going to let the process exit on each of these. Another Node.js module (trivial, 30 LoC) can run the dro process and restart it when it ends, with exponential back-off. We can continue to write dro module code without thinking about error handling.

This may not be the right approach in the long term. It would be nice to have every contract function call in the code that results in a JSON RPC API call to the provider (eg. see https://github.com/biketracker/dro/issues/1) go through some error handling and back-off. For one, we can't very well parse the error response and handle one error differently from another with this approach.

As I learn React, I'm going to see how web-based web3 codebases handle losing network connectivity or error HTTP responses, starting with the Uniswap interface (https://github.com/Uniswap/interface). There should be plenty of established good practice for this sort of thing in web3 by now (although the browser environment if a bit different to the server).

eliotstock / dro

Move error handling and back-off to a separate process (for now) #9