Explorer: First Run of App / Error Modes

[tjayrush]

Error Modes on Startup:

1. API is not running
2. RPC is not running
3. PATH is incorrect (can't find chifra or it's children)
4. Error return from chifra
5. Error return from API (bad, non-existent route) -- can we remove this one -- thin API?
6. EMPTY returns (i.e no OWNED accounts)
7. Can't find PATH or PATH not set or (if we remove all the built items in ./bin of core) any of the individual executables not being present.
8. Set the paths in ~/.quickBlocks/quickBlocks.toml to invalid paths
9. Remove the entire folder ~/.quickBlocks after install
10. $PATH must contain trueblocks-core/bin
11. trueblocks-core/bin must contain chifra (assumes all other tools are available if chifra is)
12. There must be a path to the node
13. There must be an API
14. Sample data must exist for collections, monitors
15. Names data must exist and have at least X records
16. Whenblock data must exist
17. As unfortunate as it is, if the user has no Etherscan key, the API fails with bad JSON.

[tjayrush]

Old Stuff:

~Currently:~ ~Go to http://trueblocks.io~ ~Click on Download button~ ~Problem 1: This takes the user trueblocks-core, it should take the user to trueblocks-explorer~ ~At the explorer home page:~ ~Problem 2: cmake version should be cmake --version~ ~Problem 3: go --version should be go version~ ~Instructions for cloning and building seem to work, but should be tested on a fresh machine~ ~Instructions for explorer says, yarn global add forman but this fails because it needs sudo~ ~Instructions for nf start fails because nodeman is not installed. Need to add yarn add nodeman~ ~All of this leads to the app starting, but failing for some reason yet to be determined.~

~Notes on conversation with someone~ ~1) start (docker compose up) / stop / pause / restart~ ~2) "I am running."~ ~3) all it should do is start/stop.~ ~4) chifra status index~ ~5) chifra scrape~ ~6) chifra scrape pause~ ~7) chifra scrape api call doesn't return an api response, because the process never terminates. but it needs a response for the api to function.~

~Things to do:~ ~1) Find all the files that get copied into $(HOME)/.quickBlocks on running cmake ../src if any~ ~2) Find all the files that get copied with make install if any~ ~3) Distinguish between files that are needed for proper operation of QBlocks (quickBlocks.toml, names.txt, 0xTokenLib, etc.)~ ~4) Improve the copying/install process so that these files are always present in the $(HOME)/.quickBlocks folder~ ~5) Find all uses of these files in the code and change them so they always look in ~/.quickBlocks ignoring the customized cache location (do this so we can confidently tell the end user they can delete their cache at any time with no loss of function)~ ~6) Decide if copying config files to the local folder is the best way to do these things as opposed to say writing code on initialization of the libraries checks for the existence of the required file and creates is if not found~ ~7) Make this versionable, so if a user later re-installs (or re-builds after a pull), we have a way to rebuild the data in the new format if there is one.~

~Notes on Installation~ ~There are a few files that must be present for QuickBlocks to work properly. These are copied to $(HOME)/.quickBlocks on installation (at least I think they are, but this may not be consistent). The trouble is that we then refer to the files in the code based on their location depending on the end user having specified a different location for the cache:~

~Our installation simply copies the files to /usr/local/qblocks which is the right place, but I think it should copy the files to somewhere like /usr/local/qblocks-version and then soft link to the above folder to make installing future versions easier.~

~We should write an installer shell script using either Parity or IFPS as the model.~

~We may want to look into building a brew install for Mac~

~Front end should check what version of the backend it's talking to#1486~

~I spent a very long time debugging a problem that turned out to be that the backend was sending misshaped data (on one machine, I changed data fields in both front end and back end, then moved to another machine with an updated front end but not updated backend). The front end blindly worked, but was not reporting the data because the fields being sent by the backend we named in the old names. Solution: check the version of the data being sent by the backend on first start up and report a mismatch.~

[tjayrush]

Such an ancient issue. It seems it would have been fixed by now, but no....