- This was failing. Make this more lenient so the user can specify component id in the test file in a non-case-sensitive manner.
- Also switched around a wrong token order which was causing a failure (not sure we care about token order but we may in the future? Python didn't care...)
- These are just used for comparison purposes and will eventually be deleted.
- Also balancer v3 test fix: add protocol_system to yaml, and remove "excludePaths" from protobuf in substreams.yaml (this entry was not supported)
* feat: Add encoding to test suite
Use execution from simulation
Add protocol_system to all test files and pass it to run tycho
Add encoding_utils.rs
#time 5h 0m
#time 1m
#time 7m
* refactor: Move encoding swap to its own method to simplify main code
Rename encoding_utils.rs to encoding.rs
#time 20m
#time 0m
#time 0m
[copied from tycho-simulation commit msg]
Main issue:
- This was causing a big issue in the SDK testing, since accounts were being leaked between test cases. Adding this functionality provides an easy way to clear storage on the rust side, by calling .clear() between subsequent tests.
How this manifested:
- Incorrect pool balances were being loaded in the BalancerV2SwapAdapter if tests were run altogether.
- Pool balances were correct if tests were run in isolation.
- We checked that tycho-indexer returned correct pool balances, and we checked pool balances for that block on-chain to be double-sure
- In the python test suite, which was passing, there was code which dropped the whole database between subsequent tests, which was not being duplicated in the rust suite.
This is why we weren't getting BAL510 for `test_erc4626_linear_pool_creation` in python - simulation was being skipped, though not skipped in the rust porting. The simulation is skipped here since no liquidity has been added in more than 100k blocks.
This was the most elegant solution we could come up with at the moment for having the proper adapter in the builder.
Notes:
- The default adapter bytecode in tycho-simulation is still loaded at compile time.
- If the adapter bytecode is passed to the decoder, it will be loaded dynamically at runtime and used instead the bytecodes in tycho-simulation.
- The adapter bytecode is used in the builder to get capabilities and thus spot prices before returning the state, so just overwriting the adapter in the state is way too cumbersome. We went with this solution since it was the lesser evil, even though we know it leaks VM-specific info to non-vm protocols (which was already being done anyway with the balances).
* feat: update balancer v2 spkg to make it return old slot values
This is needed for the new DCI version that uses old values to look into exactly what part of the slot change and compare with the retrigger offset
* refactor: use crate registry instead of github
---------
Co-authored-by: zizou <111426680+flopell@users.noreply.github.com>
* feat: Pass adapter contract to decoder
This was the most elegant solution we could come up with at the moment for having the proper adapter in the builder.
Notes:
- The default adapter bytecode in tycho-simulation is still loaded at compile time.
- If the adapter bytecode is passed to the decoder, it will be loaded dynamically at runtime and used instead the bytecodes in tycho-simulation.
- The adapter bytecode is used in the builder to get capabilities and thus spot prices before returning the state, so just overwriting the adapter in the state is way too cumbersome. We went with this solution since it was the lesser evil, even though we know it leaks VM-specific info to non-vm protocols (which was already being done anyway with the balances).
* feat: Take a struct of vm_attributes instead of just adapter path
So that we don't need to change the interface in the future
* chore: remove comment - we are no longer blocked
This is fixed with the latest change to pass adapter contract to decoder
* feat: Use DecoderContext instead of VMAttributes
- More easily extendable
- Doesn't break the existing decoder interface
---------
Co-authored-by: TAMARA LIPOWSKI <data.lipowski@extaccount.com>
