-
Notifications
You must be signed in to change notification settings - Fork 0
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
Code restructuring #50
Conversation
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.
Hey the structure is looking really good here. I noticed that the "orderbook_api" class has a lot more than just API calls though... might want to consider separating some of that logic.
I made lots of inline suggestions and comments! but its already looking really nice!
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.
Looks very good so far. Did a first pass and will do another one tomorrow.
src/apis/orderbookapi.py
Outdated
) -> list[dict[str, Any]]: | ||
""" | ||
This function uses a list of tx hashes to fetch and assemble competition data | ||
for each of the tx hashes and returns it. |
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.
Might make sense to add a comment that links to the schema that is returned by the competition endpoint. Don't have a direct link but maybe we can add this:
https://api.cow.fi/docs/#/default/get_api_v1_solver_competition_by_tx_hash__tx_hash_
src/apis/web3api.py
Outdated
transactions = [] | ||
|
||
settlement_hashes_list = [] | ||
# transactions may have repeating hashes, since even event logs are filtered |
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.
Just checked and it seems that trade events are appearing here, so a single settlement hash will appear N times, where N is the number of orders being executed in it. This is due to the topics filter criterion set above, which corresponds to trade events. Maybe good to add a clarifying comment here.
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.
why not just listen for settlement events and get the trade events from the tx receipt? Are we listening for trade events?
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.
In my tests, settlement events also happened in transactions not being settlements (but some kind of Safe approval thing). Therefore I stuck with trade events.
- implement trade, order, execution classes - split API calls into different classes: Web3 and Orderbook - define base_test class - implement fee test on top of base_test class
- use list, tuple, dict instead of List, Tuple, Dict - use SETTLEMENT_CONTRACT_ADDRESS instead of ADDRESS - use different string format in some of the logging - split fee test into smaller functions - use dataclass decorator for some classes - make BaseTest an abstract base class
- split cost coverage and quote test into two tests - implemented a modified daemon: each test has its own hash list to check - made time out a constant REQUEST_TIMEOUT = 5 (seconds) - added new constants for cost_coverage - renamed trades.py to models.py - use fstrings in logging
f1695d9
to
c919afc
Compare
- loading json - pulling out urls for prod and barn - fixed bug in run_queue function
- fix barn address - fixed typo in function doc string
checks if other solutions have settled orders from the winning settlement with more surplus - surplus difference is computed as before relative difference is computed slightly differently: price_win / price_alternative - 1 =(for fill-or-kill)= diff_surplus / surplus_token_amount instead of diff_surplus / surplus_token_limit_amount prices take fee into account: price = (sell_amount + fee_amount) / buy_amount for all order types
Some things still to be done:
Things to do later:
|
- files for old test - organized constants file - added an __init__.py for apis
- ebbo violations are logged as errors - caught connection errors are raised as warnings - if bounds are almost violated, an info message is logged - if no bounds are violated, debug info is logged
should be enabled again later
src/apis/orderbookapi.py
Outdated
return None | ||
except requests.exceptions.ConnectionError as err: | ||
self.logger.warning( | ||
f"Connection error while fetching competition data: {err}" |
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.
Maybe it would be good to include the request that caused the exception? I am thinking mostly to include the tx hash in the error msg, in case we might need it when debugging.
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.
Good idea.
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.
Fixed.
src/apis/orderbookapi.py
Outdated
json=request_dict, | ||
timeout=REQUEST_TIMEOUT, | ||
) | ||
except ValueError as err: |
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.
Again, is it possible that we get some other exception here and the script "crashes"?
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.
Not sure anymore why I used a different error here. Will have a look at what types of errors are possible and catch 'em all. (In the sense of 'what types of errors are typically returned by a post request'. In python, anything can happen a run time.)
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 changed the error type.
src/daemon.py
Outdated
test.add_hashes_to_queue(tx_hashes) | ||
web3_api.logger.debug(f"Running test ({test}) for hashes {test.tx_hashes}.") | ||
test.run_queue() | ||
web3_api.logger.debug("Test completed.") |
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.
Maybe have a msg Test completed for hash 0x...
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.
Do you mean we should keep track of all the tests which where completed? Maybe I should just move those debud statements into run_queue
where more info on hashes and test results is available.
- catch more requests errors - add request information to logs for connection errors - made `get_tx_hashes_by_block` return None in case of connection error - add logger to base test class, removed logger from sub classes - add debug info for checked hashes
A lot of things have changed in this PR and we would like to proceed with merging so that we finally have a working version of it which we can build on. Thus, I am dropping this review so that we can speed things up.
This is a draft PR to show how the new structure of the EBBO code could look like.
Web3API
andOrderbookAPI
are implemented.BaseTest
. They haveTrades
,OrderData
,OrderExecution
are implemented.