Closed viper7882 closed 4 months ago
This is expected, as the settleAuction
will fetch a lot of slots in each sequence:
/// @notice Settle auctions
/// @param auctionIds IDs of the auctions to be settled
function settleAuction(uint[] memory auctionIds) public {
(uint[] memory ids, uint[] memory bidAmounts, uint totalAmount) = _getOpenAuctionsBidSizes(auctionIds);
require(totalAmount > ZERO, "GebUniswapV3KeeperFlashProxyETH/all-auctions-already-settled");
bytes memory callbackData = abi.encodeWithSelector(this.multipleBid.selector, ids, bidAmounts);
_startSwap(totalAmount, callbackData);
}
It seems the correct way to run this will be to either use a local node or optimize the fuzzing to select valid auction numbers for the list.
I see, thank you @ggrieco-tob for your help. Closing this issue
Describe the issue:
Hi admin,
Besides Long time fetching slots reported here, for unknown reason it took extraordinary time to run onchain fuzzing on the even simpler
test
contract. Essentially there is only oneuint256[] memory
function and optimization function. The calls/s is always 0. I'm uncertain if zero calls per second is related to larger than normal number of slots fetched for this contract. As I have no control over number of slots fetched, it is best for you to investigate.I didn't see similar issue on other contracts with
uint256[] memory
function. Hopefully you could shed some light on what's going on in the fuzzer for this simple contract.Code example to reproduce the issue:
echidna-config.yaml
Hevm.sol
test.sol
Command:
Version:
Echidna 2.2.2 0.10.1
Relevant log output:
Observation: While the Calls/s remains at 0, the number of Fetched Slots are keep increasing as time passing by.