refactor: Improve non-strict-mode to make it even less strict #387
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
eduohe
approved these changes
Nov 30, 2023
morgsmccauley
force-pushed
the
refactor/improve-non-strict-mode
branch
from
09371ee to
b999547
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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)