-
Notifications
You must be signed in to change notification settings - Fork 26
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
maxDeposit() implements a upper bound: test fails with "The vm.assume
cheatcode rejected too many inputs"
#3
Comments
vm.assume
cheatcode rejected too many inputs"vm.assume
cheatcode rejected too many inputs"
There are multiple options.
|
@daejunpark I have tried all the suggested options none of them seem to work |
@Tunji17 would you mind providing reproduction examples for that? |
I was trying to run these tests against a basic solmate implementation of the 4626 vault, I kept getting this error
All the tests are failing out of the box, i have tried increasing |
@Tunji17 Were you able to find a solution to the problem? I am facing the same issue. All tests fail due to |
@0xmonsoon No, i gave up and just used the tests provided by solmate, then converted the ones with input to fuzzy tests |
I am having the same problem as @Tunji17 and @0xmonsoon.
|
SAME ISSUE |
We are integrating the property test suite as part of the verification of our vault contracts. Unfortunately all tests are failing with the following error:
I figured that the problem might be related to the fixed upper boud in the
maxDeposit()
of the function. The function is implemented to limit the number of assets in the vault. Removing the bound let the test pass, but it does not make sense w.r.t to the contract's logic.Is it possible to bound the "assets" value in fuzzer? For example, an input of
4888566203988820057829237745407778857278425300380918631855130364758515
does not make sense in our case.Thanks!
The text was updated successfully, but these errors were encountered: