fix: get delay for advancing time from the proposal instead of constant#495
fix: get delay for advancing time from the proposal instead of constant#495
Conversation
🦋 Changeset detectedLatest commit: d2bd5e6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
There was a problem hiding this comment.
Pull Request Overview
This PR improves time advancement logic in the Chainlink deployments framework by replacing a hardcoded time delay constant with dynamic retrieval from proposal configuration.
- Removed the hardcoded
defaultAdvanceTimeconstant (36000 seconds/10 hours) - Updated time advancement to use
cfg.timelockProposal.Delay.Seconds()for more accurate proposal-specific timing - Added documentation in changeset noting the switch from constant to proposal-based delay
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| engine/cld/legacy/cli/mcmsv2/mcms_v2.go | Removed hardcoded time constant and updated time advancement to use proposal delay |
| .changeset/pretty-days-draw.md | Added changeset documentation for the delay calculation change |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| lggr.Info("Waiting for the chain to be mined before executing timelock chain command") | ||
| if err = anvilClient.EVMIncreaseTime(defaultAdvanceTime); err != nil { | ||
|
|
||
| if err = anvilClient.EVMIncreaseTime(uint64(cfg.timelockProposal.Delay.Seconds())); err != nil { |
There was a problem hiding this comment.
Converting time.Duration to uint64 via Seconds() may lose precision for sub-second delays and could truncate fractional seconds. Consider using a more precise conversion or validating that the delay is appropriate for the EVMIncreaseTime API.
| if err = anvilClient.EVMIncreaseTime(uint64(cfg.timelockProposal.Delay.Seconds())); err != nil { | |
| // Round up to the nearest whole second to avoid truncating sub-second delays | |
| delaySeconds := uint64((cfg.timelockProposal.Delay + time.Second - 1) / time.Second) | |
| if err = anvilClient.EVMIncreaseTime(delaySeconds); err != nil { |
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## chainlink-deployments-framework@0.55.0 ### Minor Changes - [#492](#492) [`7243af8`](7243af8) Thanks [@jkongie](https://github.com/jkongie)! - update aptos dep to v1.9.1 - [#474](#474) [`fdcf28d`](fdcf28d) Thanks [@ecPablo](https://github.com/ecPablo)! - add predecessors and opcount calculation logic to proposalutils package. ### Patch Changes - [#496](#496) [`fea372c`](fea372c) Thanks [@graham-chainlink](https://github.com/graham-chainlink)! - fix: update db controller to accept context - [#498](#498) [`ce51cbe`](ce51cbe) Thanks [@gustavogama-cll](https://github.com/gustavogama-cll)! - fix: anvil env should check for addresses from DataStore as well - [#495](#495) [`126609e`](126609e) Thanks [@ecPablo](https://github.com/ecPablo)! - get delay for advancing time from the proposal instead of constant value - [#497](#497) [`976d232`](976d232) Thanks [@graham-chainlink](https://github.com/graham-chainlink)! - fix(catalog/memory): remove dependency on testing.T --------- Co-authored-by: app-token-issuer-engops[bot] <144731339+app-token-issuer-engops[bot]@users.noreply.github.com>





This pull request updates how the time delay for advancing the blockchain is determined in the Chainlink deployments framework. Instead of using a hardcoded constant, the delay is now dynamically retrieved from the proposal configuration, improving flexibility and accuracy.
Improvements to time advancement logic:
defaultAdvanceTimewas removed frommcms_v2.go, so time advancement no longer relies on a fixed value.cfg.timelockProposal.Delaywhen callinganvilClient.EVMIncreaseTime, ensuring the time advancement matches the proposal's requirements.Documentation update:
.changeset/pretty-days-draw.mdfile documents this change, noting that the delay for advancing time is now obtained from the proposal rather than a constant value.