Deterministic testing integration #671
Conversation
| "name":"createStrategy", | ||
| "stateMutability":"payable", | ||
| "inputs":[{"internalType":"Token","name":"token0","type":"address"},{"internalType":"Token","name":"token1","type":"address"},{"components":[{"internalType":"uint128","name":"y","type":"uint128"},{"internalType":"uint128","name":"z","type":"uint128"},{"internalType":"uint64","name":"A","type":"uint64"},{"internalType":"uint64","name":"B","type":"uint64"}],"internalType":"structOrder[2]","name":"orders","type":"tuple[2]"}], | ||
| "outputs":[{"internalType":"uint256","name":"","type":"uint256"}] |
There was a problem hiding this comment.
These two contract functions (createStrategy and deleteStrategy) are functions which change the state of the contract (aka write functions).
They are not supposed to ever be used by the bot, even though they can technically be executed in read-only mode (aka static call).
If this is indeed how you're using them, then there is very likely a better way (i.e., calling an actual read function in the same contract).
| @@ -358,7 +358,7 @@ def _run( | |||
| ) | |||
| return | |||
|
|
|||
| tx_hash, tx_receipt = self._handle_trade_instructions(CCm, arb_mode, r, replay_from_block) | |||
| tx_hash, tx_receipt, log_dict = self._handle_trade_instructions(CCm, arb_mode, r, replay_from_block) | |||
There was a problem hiding this comment.
No changes in this file until PR #651 is merged
| @@ -132,9 +133,9 @@ def validate_and_submit_transaction( | |||
| self.cfg.logger.info(f"Waiting for transaction {tx_hash} receipt") | |||
| tx_receipt = self._wait_for_transaction_receipt(tx_hash) | |||
| self.cfg.logger.info(f"Transaction receipt: {dumps(tx_receipt, indent=4)}") | |||
| return tx_hash, tx_receipt | |||
| return tx_hash, tx_receipt, log_dict | |||
There was a problem hiding this comment.
Passing an additional input parameter just in order to return it seems futile.
You can easily determine on the caller function that log_dict is valid if and only if tx_hash and tx_receipt are valid.
The deterministic testing is a critical component to the testing infrastructure.
This PR rebases onto the release candidate with some important fixes.
Most critically, an additional logging component has be (re)added into the transaction txt files that are created following a successful transaction