fix(tools/cosmovisor): do not download all binaires with autodownload #23653
Conversation
📝 WalkthroughWalkthroughThe pull request modifies the Changes
Sequence Diagram(s)sequenceDiagram
participant Caller as Caller
participant UB as UpgradeBinary
participant DL as Downloader
Caller->>UB: Call UpgradeBinary()
UB->>UB: Check if binary exists
alt Binary exists
UB->>Caller: Return existing binary
else
UB->>UB: (Validation step removed)
UB->>DL: Initiate binary download
DL-->>UB: Return downloaded binary
UB->>Caller: Set and return binary
end
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yml 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (1)`**/*.md`: "Assess the documentation for misspellings, gramm...
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
The only place that this validation should take place is during the proposal submission process.
I am not sure I totally agree with this, you can always submit an invalid proposal.
F.e those that are using the CLI but pass --no-validate or those that just craft their proposal from somewhere else. I think it is good to have node operator (and so effectively cosmovisor, to do that verification, and won't switch to an invalid binary).
However, I do see the use case for not validating the upgrade info as well.
Maybe an option to add in the Cosmovisor config and just skip it here if true?
I don't understand what scenario downloading and checking everything twice actually prevents? The checksum will still be required to be verified in the Once the upgrade height has hit, it's not like the old binary is useable anyway right?
Yeah I can do it that way if it will allow us to get this done faster. |
|
You are right! I missed that we would be using go-getter earlier. This is fine as is indeed. Could you add a changelog entry (tools/cosmovisor/changelog.md) |
Yes I will once #23652 is merged. Otherwise we will hit a merge conflict? |
|
@gartnera merged and up to date! |
Description
As described in #19871,
cosmovisorwill currently try to download binaries for all platforms and architectures. This is bad for several reasons:This logic was responsible for some issues during the @zeta-chain v27 upgrade since we had messed up one of the checksums in the upgrade proposal.
The only place that this validation should take place is during the proposal submission process.
Author Checklist
I have...
!in the type prefix if API or client breaking changeCHANGELOG.mdprepare-upgradewhen non archive #23652 is merged to avoid conflictsReviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
Please see Pull Request Reviewer section in the contributing guide for more information on how to review a pull request.
I have...
Summary by CodeRabbit
Summary by CodeRabbit
Bug Fixes
Refactor