Simulate timelock operations on fork

[shahthepro]

Code Change Checklist

To be completed before internal review begins:

• The contract code is complete
• Executable deployment file
• Fork tests that test after the deployment file runs
• Unit tests *if needed
• The owner has done a full checklist review of the code + tests

Internal review:

• Two approvals by internal reviewers

Deploy checklist

Two reviewers complete the following checklist:

- [ ] All deployed contracts are listed in the deploy PR's description
- [ ] Deployed contract's verified code (and all dependencies) match the code in master
- [ ] Contract constructors have correct arguments
- [ ] The transactions that interacted with the newly deployed contract match the deploy script.
- [ ] Governance proposal matches the deploy script
- [ ] Smoke tests pass after fork test execution of the governance proposal

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 51.00%. Comparing base (1b78421) to head (62ea722).
Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2375   +/-   ##
=======================================
  Coverage   51.00%   51.00%           
=======================================
  Files          92       92           
  Lines        4515     4515           
  Branches     1198     1198           
=======================================
  Hits         2303     2303           
  Misses       2209     2209           
  Partials        3        3           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sparrowDom]

I think we should also check the fork's block number. If some older block number is set in the contracts/.env then skipping the file isn't such a good idea.
Should we soft enforce that users need to have at least a week / 2 weeks old block number in env file fork the forkend environment to run? Which can be force overridable ofc

[shahthepro]

That's a good point. But I don't think hardhat migrations would work if you use an older block. I know for sure that the blocknumber is encoded into all the artifacts, so will have to nuke them all and remove the entries from migrations.json file manually to do that. If we are gonna have to remove the entries from migrations.json manually, it'll have a newer timestamp when it runs again on fork from the block number you forked.

But if there's any other usecase that I'm missing here, let me know, I can see what our options are

[sparrowDom]

I might be understanding this incorrectly. Lets say I have a month old Block number in .env file. And that there were migrations that happened after that. Won't all the migrations that are younger than my block number, but older than 14 days from today be skipped? Ideally all would need to be applied.

[shahthepro]

Won't all the migrations that are younger than my block number, but older than 14 days from today be skipped?

This is true. Yes. However, hardhat wouldn't run those migrations either unless we remove the entries from .migrations.json (or give it a different name, like overriding main.id to be something new).

This piece of code doesn't skip older migrations but more like it forces hardhat to rerun migrations that happened in the last 14 days (so that we can figure out if it has a proposal that needs to be simulated). This is where that happens: https://github.com/OriginProtocol/origin-dollar/blob/shah/base-simulation-timelock-ops/contracts/utils/deploy-l2.js#L430

[shahthepro]

I'm gonna merge this in, since the change might cause several merge conflict if left open for long. But happy to address your concerns in a new PR or branch when we make a decision there

[naddison36]

this is clever. I like how we are now storing the Safe json files for the Timelock schedule and execute batch in the repo.