fix: clarified Redis connection errors and added Redis dependency to docker-compose files #278
Conversation
There was a problem hiding this comment.
Hello! Thank you! I think we should use radis for development. It will only be used if we have a running instance of near_state_indexer which is based on nearcore. I would like you to check at the initialization stage whether the connection to redis is established and if there is an error then do not spawn the tasks update_final_block_regularly_from_redis, update_optimistic_block_regularly, OPTIMISTIC_UPDATING.set_not_working()
and generated a Warning error. This way you won't have to carry dependencies in all places.
I would also like you to update the readme.md specify redis as an optional dependency and describe its use only when paired with near_state_indexer.
Should it be done in root I've added some info to |
It's enough for now, we'll perform docs cleaning later. |
…docker-compose files (#278) * feat: provided better error message in case "Connection refused" caused by Redis * feat: added redis dependency to docker compose files * feat: made redis an optional dependency * chore: downgraded block fetching error logs to the warn level * chore: set `OPTIMISTIC_UPDATING` to not working * docs: added info about Redis
Improve the error to make it less ambiguous, we need a clear message identifying it is related to connection to Redis
Before:
After:
Update the
docker-compose.ymlto ensure it is always in a working condition todocker-compose upfrommainTo complete this, I've added redis dependency to postgres and rightsizing docker-compose files
Decide how to proceed with having Redis as a mandatory dependency and whether the
rpc-servercan work without it even with limited capabilitiesIn any case we can merge these minor fixes now and later (@kobayurii @khorolets) will decide wether Redis is required or not
closes #274
closes #279