-
Notifications
You must be signed in to change notification settings - Fork 90
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
Update settlement contract balances in background task #2108
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.
Top-Notch
if let Some(balance) = balances.remove(key) { | ||
entry.balance = balance; | ||
} else { | ||
tracing::info!(?key, "key without balance update"); |
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.
What is the purpose of the INFO
level 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.
It's supposed to help us to debug the rare race condition where we add a new token balance to the cache while the cache update is in flight.
The new item may not be updated (it should be up to date but in theory the block could also have just changed) and therefore we could pass a slightly outdated buffer list to the solvers. Again, I think this is extremely rare, but if it happens we can at least see if from the logs now.
Description
Addresses the bug that we currently fetch settlement buffer balances once per token and don't update them in between auctions, which can lead to solutions relying on outdate internal buffer balance information and thus incorrectly marking interactions as internalizable causing simulation to fail.
Changes
This approach is a bit wasteful, as token balances only really change when a settlement trading this token is included on-chain. However, getting that information in this component is non-trivial. Moreover, some tokens exhibit custom balance logic (e.g. rebasing tokens) which could update the contract balance even without a settlement taking place.
If we deem this approach too inefficient, I would suggest we restrict the number of tokens we cache (using an LRU cache) and re-fetch all relevant information (including decimals and symbol) in case of a cache miss.
If we don't want to lose caching of decimals and symbols for some tokens, I'd suggest splitting the fetcher into two components, one for static information, and one more
RecentBlockCache
like component for the settlement balances.Let me know what you think.
How to test
Added an end to end test which fails without the changes in
driver::infra::tokens
Related Issues
Fixes #2093