-
Notifications
You must be signed in to change notification settings - Fork 11
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
THE BIG ONE 🐘 💣 🚝 #501
THE BIG ONE 🐘 💣 🚝 #501
Conversation
@RyRy79261 tackled the fork tests here: #503 because it felt like a bigger beast and worth keeping separate. The reasons these were failing here weren't related to the changes in the branch, they were just a bit flakey, Hopefully you should see all green on the other PR. |
This reverts commit ac1c540. Brings back the maxTimestampSpread setting. A visual explanation here: <img width="918" alt="image" src="https://github.com/user-attachments/assets/02dfaadb-f029-4f38-8bd5-965644b4a4b5"> We need it because CELO/USD has a heartbeat of 24hr and PHP/USD 5minutes, therefore we could be in a situation where the spread between reports is quite large, and if we rely only on max timestamp spread we could be reporting with stale data. The rule of thumb is: - Set `maxTimestampSpread` by considering the largest heartbeat frequency. - Set `tokenExpiry` in SortedOracles by considering the shortest heartbeat frequency. N/A Yup N/A N/A N/A --------- Co-authored-by: chapati <[email protected]> Co-authored-by: philbow61 <[email protected]>
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 noticed it sometime takes time for already built contracts between running the forge test
and compilation starts(2-3 mins) and also between compilation ends and tests run(2-3 mins). It basically stays there without any feedback. I guess that is caused by the foundry version and won't be an issue after the latest PR of eliminating the need for viaIR.
@baroooo yeah I noticed that as well (and commented on the foundry WIP branch about it) but yeah like you said it's not a problem cose it will go away completely with the other PR. |
Description
As I told some of you at dinner, I've had a bad case of insomnia over the last week. This PR resulted from a couple of late night coding sessions and the incessant need to make things nicer in our repos.
It's a big PR but 𝚫code is negative so 🤷 .
What happens in this mondo-PR:
celo
contracts are removed form the repo and replaced with the@celo/contracts
NPM package. With a small caveat.interfaces
are made to work with0.8
and cover more of the contract functions.tests
contracts are updated to0.8
and usedeployCode
helpers to deploy lower-version contracts, and the use the interfaces to interact with them.We make use of this [wip] feat: compilation restrictions foundry-rs/foundry#8668 to improve compile time.solhint
andprettier
to a recent version and fix/ignore all issues.@celo/contracts
The only caveat of using the
@celo/contracts
package is thatUsingRegistry.sol
in there needs to import things frommento-core
and I didn't manage to get it working ok with remappings, so I kept a copy ofUsingRegistry.sol
incontracts/common
. It's only used inswap/Reserve.sol
and when we remove it from there we can completely killcommon
.The foundry WIP PR
A better solution was found here #502, which removes the need for
via-ir
completely.The reason it takes so long to compile our code is because we needvia-ir
forAirgrab.sol
andStableTokenV2.sol
, andvia-ir
is super slow. But with the compiler restrictions implemented in foundry-rs/foundry#8668 we can have multiple compiler profile settings for subgraphs of the source-graph, which compile in parallel with different settings.You can easily install that version of foundry locally, (you have to have rust installed tho):With this version of foundry and the settings infoundry.toml
, if you're not working in a part of the source graph that containsAirgrab.sol
orStableTokenV2.sol
, compilation will happen withoutvia-ir
and will be super snappy. However if you do touch that source graph it will still take noticeably long. Right now on my machine full clean compilation takes 80seconds. It used to take >3minutes.ForkTest Refactoring
Our fork tests can get a bit heavy because they're running test assertions for all the exchanges in a single test call. I've refactor it a bit and split out exchange assertions into their own tests contracts that need to be manually created when new exchanges are deployed. There's a chain-level assertion on the number of exchanges that helps us catch this and keep them up to date.
This work was continued here #503 for a much cleaner solution.
Other changes
no minor changes here, no :))
Tested
Tested? Tested!
Related issues
Fixes the issues in my head.
Backwards compatibility
What even is that?
Documentation
Holy Bible