-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Dequeue minimum guaranteed logs as a priority #13179
base: feature/AUTO-9357
Are you sure you want to change the base?
Conversation
I see you updated files related to
|
Quality Gate passedIssues Measures |
latestBlockWindow, _, isWindowComplete := getBlockWindow(latestBlock, blockRate) | ||
|
||
var dequeuedLatestCompleteWindow bool | ||
// if the current latest window is incomplete, check that we have dequeued the second most recent window |
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.
let's ensure we dequeue logs from an incomplete window before moving to best effort as o/w we'll introduce delay for latest blocks
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.
The more I think about this, I'm not sure how we can do this without introducing some delay for some upkeeps? E.g if we choose to dequeue from non-complete windows, imagine this scenario, for a 2 block window:
- First block contains logs for upkeeps 1 and 2
- Second block contains logs for upkeeps 2 and 3
If we choose to dequeue on an incomplete block window, when only the first block exists, we'll dequeue potenitally the min number of upkeeps for upkeeps 1 and 2, and this window will be considered as having its minimum commitment met, which would starve upkeep 3?
If we choose to dequeue on complete windows, then we would switch over to best effort mode until the block window was complete, and once both blocks were available, we'd dequeue min commitment for this window, before resuming best effort.
if !isWindowComplete { | ||
penultimateBlockWindow, _, _ := getBlockWindow(latestBlock-int64(blockRate), blockRate) | ||
|
||
if dequeuedPenultimate, ok := p.dequeuedMinimum[penultimateBlockWindow]; ok { |
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.
q. is this state reset by reorgs?
https://smartcontract-it.atlassian.net/browse/AUTO-10165
In this PR, we're modifying the log provider to dequeue the minium number of guaranteed logs across all block windows as a priority, before comitting to best effort execution.
As an example, if we have 2 upkeeps and 3 block windows, each with 10 logs to be dequeued in total (5 per upkeep), and assuming a limit of 1 log per upkeep, we would:
At this point, minimum commitment for all three block windows has been fulfilled, we can now operate on a best effort basis, going back to block window 1: