-
Notifications
You must be signed in to change notification settings - Fork 212
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
Verify in devnet that 3rd party Oracle operators re-sync when priceFeeds are replaced #9886
Labels
Comments
Chris-Hibbert
added
enhancement
New feature or request
test
contract-upgrade
oracle
Related to on-chain oracles.
labels
Aug 13, 2024
This was referenced Aug 13, 2024
dckc
changed the title
Verify in devnet that Oracles re-sync when priceFeeds are replaced
Verify in devnet that 3rd party Oracle operators re-sync when priceFeeds are replaced
Aug 29, 2024
mergify bot
added a commit
that referenced
this issue
Oct 9, 2024
closes: #9584 closes: #9928 refs: #9827 refs: #9748 refs: #9382 closes: #10031 ## Description We added upgrading the scaledPriceAuthority to the steps in upgrading vaults, auctions, and priceFeeds, and didn't notice that it broke things. The problem turned out to be that the "priceAuthority" object registered with the priceFeedRegistry was an ephemeral object that was not upgraded. This fixes that by re-registering the new priceAuthority. Then, to simplify the process of cleaning up the uncollected cycles reported in #9483, we switched to replacing the scaledPriceAuthorities rather than upgrading them. We also realized that we would need different coreEvals in different environments, since the Oracle addresses and particular assets vary for each (test and mainNet) chain environment. #9748 addressed some of the issues in the original coreEval. #9999 showed what was needed for upgrading priceFeeds, which was completed by #9827. #10021 added some details on replacing scaledPriceAuthorities. ### Security Considerations N/A ### Scaling Considerations Addresses one of our biggest scaling issues. ### Documentation Considerations N/A ### Testing Considerations Thorough testing in a3p, and our testnets. #9886 discusses some testing to ensure Oracles will work with the upgrade. ### Upgrade Considerations See above
mergify bot
pushed a commit
that referenced
this issue
Oct 18, 2024
refs: #9886 ## Description Some tests in DevNet indicate that the Oracles need the roundID in vstorage to be reset so they can sync. ### Security Considerations Not a security issue. ### Scaling Considerations Not directly a scaling concern. (see #8400). ### Documentation Considerations not user visible. It would be nice if the protocol between oracles and fluxAggregators were documented somewhere ### Testing Considerations updated the a3p tests to increment the roundId before the upgrade and show that this upgrade resets it. ### Upgrade Considerations This change is to the fluxAggregator which is already being started afresh in this proposal.
In DevNet, the oracle operators were able to re-sync, though it took manual intervention. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
What is the Problem Being Solved?
When we replace the PriceFeed vats, we'll need to ensure that the third-party oracles restart successfully. This can be done in devnet.
Description of the Design
run a coreEval, accept invitations for new priceFeeds, ensure the oracles are able to feed prices to them, or repair the middleware.
Security Considerations
N/A
Scaling Considerations
N/A
The text was updated successfully, but these errors were encountered: