-
Notifications
You must be signed in to change notification settings - Fork 63
fix: the projection now always stores blocks when it reaches tip - k #1208
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: the projection now always stores blocks when it reaches tip - k #1208
Conversation
|
5f072a6
to
6690a71
Compare
Jira ticket created retrospectively for this: https://input-output.atlassian.net/browse/LW-10276 |
6690a71
to
fbe9f54
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!
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.
Great work! 🚀
evt.eventType === ChainSyncEventType.RollBackward || | ||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
evt.eventType === ChainSyncEventType.RollBackward || willStoreCheckers.some((check) => check(evt as any)) | ||
willStoreCheckers.some((check) => check(evt as any)) || | ||
willStoreBlockData(evt) |
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.
Very minor improvement: I suggest making this the 1st condition (before evt.eventType === ChainSyncEventType.RollBackward
), because this predicate is very cheap, and once it reaches tip-k it won't have to ever run any other predicates. If you make this change, feel free to squash right away.
ba01291
fbe9f54
to
ba01291
Compare
Context
We are getting an error in the projection service on rollback:
Error: Could not rollback to bed4a6a2e9cf54d61cd56dd06d7b5e9990e7a51cebb137b48316df92df5ee439: tip block not found in stability window buffer
This is because the projection services now selectively stores blocks based on which stores are enabled and certain conditions, however, for rollback purposes we should always store the blocks inside the stability window.
Proposed Solution
Always stores block when the projection reaches tip - k height.