skip liquidation task loop if last committed block height is the same #2124
Conversation
WalkthroughThe recent changes enhance error handling in tests and optimize the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (2)
- protocol/daemons/liquidation/client/grpc_helper_test.go (1 hunks)
- protocol/daemons/liquidation/client/sub_task_runner.go (2 hunks)
Additional comments not posted (4)
protocol/daemons/liquidation/client/sub_task_runner.go (3)
29-31: Addition oflastLoopBlockHeightfield is appropriate.The new field
lastLoopBlockHeightis necessary for tracking the last processed block height, which supports the optimization logic.
55-61: Conditional check for skipping the task loop is correctly implemented.The logic to skip the task loop when
lastCommittedBlockHeightequalss.lastLoopBlockHeightis correctly implemented, preventing unnecessary processing.
63-63: UpdatinglastLoopBlockHeightis correctly placed.The update of
s.lastLoopBlockHeighttolastCommittedBlockHeightensures that the state is accurately maintained for the next iteration.protocol/daemons/liquidation/client/grpc_helper_test.go (1)
593-597: Enhanced error handling logic is correctly implemented.The conditional structure accurately differentiates between expected and unexpected errors, improving the specificity of error assertions.
| return nil | ||
| } | ||
|
|
||
| s.lastLoopBlockHeight = lastCommittedBlockHeight |
There was a problem hiding this comment.
Playing devil's advocate: are we sure this is thread-safe? Could two liquidation daemon loop overlap? Should we add a sync.Mutex similar to LiquidationServer
There was a problem hiding this comment.
no daemon loops don't overlap since we are not spawning new go routines
for {
select {
case <-ticker.C:
if err := s.RunLiquidationDaemonTaskLoop(
ctx,
client,
flags.Liquidation,
); err != nil {
// TODO(DEC-947): Move daemon shutdown to application.
client.logger.Error("Liquidations daemon returned error", "error", err)
client.ReportFailure(err)
} else {
client.ReportSuccess()
}
case <-stop:
return
}
}
| @@ -50,6 +52,16 @@ func (s *SubTaskRunnerImpl) RunLiquidationDaemonTaskLoop( | |||
| return err | |||
| } | |||
|
|
|||
| if lastCommittedBlockHeight == s.lastLoopBlockHeight { | |||
There was a problem hiding this comment.
IIUC if application restarts, lastLoopBlockHeight is by default 0 and we always continue below logic. If so could we document?
| return nil | ||
| } | ||
|
|
||
| s.lastLoopBlockHeight = lastCommittedBlockHeight |
There was a problem hiding this comment.
Nit: I wonder if here's the best place to assign s.lastLoopBlockHeight = lastCommittedBlockHeight since we haven't sent any current block info to application yet. Wdyt think about defering the statement s.lastLoopBlockHeight = lastCommittedBlockHeight
There was a problem hiding this comment.
good question. thought about it a little bit more
putting it here strictly guarantees that loop doesn't run for the same block height, regardless of errors. If we defer the statement to the end (e.g. after SendLiquidatableSubaccountIds), theoretically it's possible that SendLiquidatableSubaccountIds only partially succeeds when first few requests goes through and later requests fail. In this case, we would be running into the same issue. I think might be slightly better here for correctness?
There was a problem hiding this comment.
defering guarantees that the s.lastLoopBlockHeight = lastCommittedBlockHeight is always run before return, even if SendLiquidatableSubaccountIds fails right? Trying to understand when we'd send SendLiquidatableSubaccountIdsagain for the same block.
No strong preference though, the current implementation also works. Up to you. Approved to unblock
There was a problem hiding this comment.
ohh you mean defer and update block height regardless of error? I misunderstood
yeah I think it's basically the same - let's keep it as is to unstuck the testnet first
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- protocol/daemons/liquidation/client/sub_task_runner.go (2 hunks)
Files skipped from review as they are similar to previous changes (1)
- protocol/daemons/liquidation/client/sub_task_runner.go
|
@Mergifyio backport release/protocol/v5.2.x |
✅ Backports have been created
|
… (backport #2124) (#2125) Co-authored-by: jayy04 <[email protected]>
|
@Mergifyio backport release/protocol/v6.x |
✅ Backports have been created
|
… (backport #2124) (#2129) Co-authored-by: jayy04 <[email protected]>
… (backport #2124) (#2125) Co-authored-by: jayy04 <[email protected]>
Changelist
[Describe or list the changes made in this PR]
Test Plan
[Describe how this PR was tested (if applicable)]
Author/Reviewer Checklist
state-breakinglabel.indexer-postgres-breakinglabel.PrepareProposalorProcessProposal, manually add the labelproposal-breaking.feature:[feature-name].backport/[branch-name].refactor,chore,bug.Summary by CodeRabbit
Bug Fixes
New Features