-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: bond escalation tests #67
Conversation
… feat/bond-escalation-tests
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.
Looks good!
When you merge dev the usage of timestamp/expected deadlines will break because of #64
vm.startPrank(disputer); | ||
|
||
// Pledge revert if break tie during tying buffer | ||
_mineBlocks(_blocksDeadline + 1); |
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.
I'd use vm.warp
instead of _mineBlocks
_mineBlocks
also updates the timestamp but I think it's clearer to handle it directly here.
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.
👍
_bondEscalationModule.pledgeForDispute(mockRequest, mockDispute); | ||
|
||
// Roll back the blocks because we need to simulate the custom error "break tie during tying buffer" and "bond escalation over" | ||
vm.warp(block.timestamp - (_blocksDeadline + _tyingBuffer + 1) * BLOCK_TIME); |
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.
I'd drop all code related to blocks deadline since we already ensure the modules only deal with relative timestamps or time windows.
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.
👍
vm.expectRevert(IBondEscalationModule.BondEscalationModule_CannotBreakTieDuringTyingBuffer.selector); | ||
_bondEscalationModule.pledgeForDispute(mockRequest, mockDispute); | ||
|
||
_mineBlocks(_tyingBuffer); |
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.
Idem above.
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.
👍
_bondEscalationModule.settleBondEscalation(mockRequest, mockResponse, mockDispute); | ||
|
||
// Mine blocks to pass the escalation deadline | ||
_mineBlocks(_expectedDeadline + 1); |
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.
but consider that _expectedDeadline
is now (after #64 was merged) the number of seconds after the creation of the request at which the ResponseModule stop accepting new responses.
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.
👍
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.
I think it's almost there. There are couple errors in how vm.warp
is used. I left a some comments, but there a few identical errors throughout the file.
vm.expectRevert(IBondEscalationModule.BondEscalationModule_BondEscalationOver.selector); | ||
_bondEscalationModule.pledgeForDispute(mockRequest, mockDispute); | ||
|
||
// Roll back the blocks because we need to simulate the custom error "break tie during tying buffer" and "bond escalation over" |
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.
Roll back the timestamp
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.
👍
_bondEscalationModule.pledgeForDispute(mockRequest, mockDispute); | ||
|
||
// Mine blocks to pass the escalation deadline | ||
vm.warp(block.timestamp + _disputeCreatedAt + _blocksDeadline + 1); |
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.
Idem above.
oracle.escalateDispute(mockRequest, mockResponse, mockDispute); | ||
|
||
// Roll back the blocks because we need to simulate the custom error "not escalatable" | ||
vm.warp(block.timestamp - (_disputeCreatedAt + _blocksDeadline + 1)); |
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.
instead you could rollback the timestamp doing vm.warp(_disputeCreatedAt)
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.
Its true, however as I know that this logic is more complex I decided to do like this in order to clarify that we are doing something "triky" and is not the natural flow
@@ -71,6 +71,9 @@ contract Integration_EscalateDispute is IntegrationBase { | |||
_disputeId = oracle.disputeResponse(mockRequest, mockResponse, mockDispute); | |||
vm.stopPrank(); | |||
|
|||
// Simulate the time passing | |||
vm.roll(1 days); |
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.
Just noticed this one. It's confusing to use vm.roll
with a time constant
… feat/bond-escalation-tests
🤖 Linear
Closes OPO-654