-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: rework optimistic indexer attempts #433
Conversation
b8ee423
to
a9d7e3e
Compare
a9d7e3e
to
2de9e82
Compare
2de9e82
to
fd10161
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! ✅
@@ -935,6 +897,32 @@ pub fn indexer_fee( | |||
} | |||
} | |||
|
|||
async fn optimistic_query( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: A small description of this function will be very helpful for the future Theo and Lorenzo 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion. Fixed.
fd10161
to
b4c678e
Compare
The gateway was originally designed with the assumption that each indexer would likely remain about as many blocks behind chain head as when it last reported its status. However, this is no longer a valid assumption when supporting file data sources and chains with wildly inconsistent block rates. This replaces the pile of spaghetti I've created to cope with these issues with something much more straightforward. Now indexer candidates are selected based on their last reported block and the last reported block is used for the deterministic query. For each selection, under some conditions we will first make an optimistic attempt at a block 2 seconds behind chain head.