You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From time to time we need to deploy a batch of contracts that depend on each other.
A recent example was the L2GaugeCheckpointer, which needed GaugeAdder V4 and its respective coordinator script contract.
When this happens, it's common to prepare the deployments before the bottom level contracts (i.e. those with less dependencies) are deployed. The fork tests for the top level contracts can still be developed, but only by deploying the dependencies within the test itself, which is not ideal. Those extra setup blocks are then removed when the dependencies are deployed and become available to the fork test.
The workflow usually goes like this:
Prepare tasks and fork tests for all contracts at the same time. Bottom level contracts' tests can be completed, top level contracts' tests require extra setup blocks that deploy the dependencies.
Review, merge and deploy bottom level contracts.
Remove extra setup blocks from top level contracts and rebase PRs.
Review, merge and deploy top level contracts.
The problem is that the fork test's block number also needs to be updated at step (3). If not updated, the test will run since the output addresses for the dependencies will be available, but the forked network will not have the contract code in those addresses at that block height. To make matters worse, the error messages are very misleading, so it's sometimes hard to get to the root cause of the problem.
The proposal would be for Task#deployedInstance to fail early when there's no contract code at the specified address.
The text was updated successfully, but these errors were encountered:
From time to time we need to deploy a batch of contracts that depend on each other.
A recent example was the
L2GaugeCheckpointer
, which neededGaugeAdder
V4 and its respective coordinator script contract.When this happens, it's common to prepare the deployments before the bottom level contracts (i.e. those with less dependencies) are deployed. The fork tests for the top level contracts can still be developed, but only by deploying the dependencies within the test itself, which is not ideal. Those extra setup blocks are then removed when the dependencies are deployed and become available to the fork test.
The workflow usually goes like this:
The problem is that the fork test's block number also needs to be updated at step (3). If not updated, the test will run since the output addresses for the dependencies will be available, but the forked network will not have the contract code in those addresses at that block height. To make matters worse, the error messages are very misleading, so it's sometimes hard to get to the root cause of the problem.
The proposal would be for
Task#deployedInstance
to fail early when there's no contract code at the specified address.The text was updated successfully, but these errors were encountered: