-
Notifications
You must be signed in to change notification settings - Fork 2
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
test(medusa): ebo request creator properties #57
base: dev
Are you sure you want to change the base?
Conversation
function property_canAlwaysCreateRequest(uint256 _epoch, uint256 _chainIdSeed) external { | ||
try HandlerParent(this).handleCreateRequest(_epoch, _chainIdSeed) {} | ||
catch { | ||
assert(false); |
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 that EpochManager::currentEpoch
is not being fuzzed, despite there's MockEpochManager::setEpoch
. Should we create HandlerEpochManager
for such purpose?
// Prevent duplicate chainId for same epoch | ||
if (_ghost_epochChainIds[_epoch][chainId]) return; |
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.
Multiple requests for a given epoch and chain ID may be created as long as:
- there is not a previous unfinished request for those arguments;
- there is not a previous finished request with response for those arguments.
function property_canAlwaysCreateRequest(uint256 _epoch, uint256 _chainIdSeed) external { | ||
try HandlerParent(this).handleCreateRequest(_epoch, _chainIdSeed) {} | ||
_epoch = _boundEpoch(_epoch); | ||
string memory chainId = _generateChainId(_chainIdSeed); | ||
|
||
// Prevent duplicate chainId for same epoch | ||
if (_ghost_epochChainIds[_epoch][chainId]) return; | ||
|
||
// Create request via EBORequestCreator | ||
try eboRequestCreator.createRequest(_epoch, chainId) {} |
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.
Are property functions state-persistent? If so, protocol interactions that are meant to alter ghost state should always be performed via the appropriate handler.
In the highlighted case, state persistency would oblige to interact via handleCreateRequest()
rather than createRequest()
.
🤖 Linear
Closes GRT-XXX