During our last refactoring sessions, we haven't paid enough attention to the non-strict mode for a while. Thus, this mode lost its nature and became too strict for its name.
In this PR I've improved this mode to help us to get back on track:
In non-strict mode we don't waste time and don't even attempt to find parent tx hash for the receipt in the DB (slow SELECT-queries make no sense for non-strict mode by slowing it down)
The amount of attempts to store ExecutionOutcomes is reduced to 5 to complete in meaningful time (1600 ms or so)
Prevent the entire indexer from shutting down if handle_message returns an error. Instead, we display a warning and proceed to the next block.
I've made a local check with an empty database setup and run an indexer with non-strict-mode + from-latest on the main net. In around 100 (or so) blocks, my indexer started writing new data to the database without massive retries. (I want to emphasize that some of the data wasn't stored as designed for non-strict-mode)
During our last refactoring sessions, we haven't paid enough attention to the
non-strict modefor a while. Thus, this mode lost its nature and became too strict for its name.In this PR I've improved this mode to help us to get back on track:
SELECT-queries make no sense for non-strict mode by slowing it down)ExecutionOutcomesis reduced to 5 to complete in meaningful time (1600 ms or so)handle_messagereturns an error. Instead, we display a warning and proceed to the next block.I've made a local check with an empty database setup and run an indexer with
non-strict-mode+from-lateston the main net. In around 100 (or so) blocks, my indexer started writing new data to the database without massive retries. (I want to emphasize that some of the data wasn't stored as designed fornon-strict-mode)