After the first deployment, implementation contracts are cached by this plugin once deployed. This saves gas for future deployments using the default settings for deployProxy, which will just make a new proxy pointed at the prior implementation address rather than redeploying the implementation contract first (since the logic already exists and you can just reuse the same address across multiple proxy storage contracts if needed)
For the Directory, we are using predicting the address based on a specific, separate directory deployer address, then passing it in to all the other contracts before actually creating the Directory. This means all Constellation contracts EXCEPT the Directory are initialized in an immutable and non-frontrunnable fashion.
This will fail if deployProxy has not been run before for the Directory because we are predicting the NEXT contract address with that address, not the SECOND!
If you run deployProxy again, the default settings for deployProxy will not redeploy the implementation unless it's changed or the cache is missing, instead just deploying the proxy itself using the next contract address as our deployment scripts expect. Therefore, subsequent deployments will succeed.
To fix this, we need to ensure that the directory deployment address that is predicted to be used for deploying the proxy is EXACTLY the one that is actually used. Doing so will require refactoring the deployment scripts to either 1) manually deploy the implementation and proxy separately or 2) utilize the redeployImplementation parameter for deployProxy().
We may also want to integrate with OZ Defender futher and use their relays for deployment so that we can use the salt parameter for deployProxy().
deployProxy()function in the hardhat-upgrades OZ plugin to deploy the protocol in deployments.ts:fastDeployProtocol()deployProxy, which will just make a new proxy pointed at the prior implementation address rather than redeploying the implementation contract first (since the logic already exists and you can just reuse the same address across multiple proxy storage contracts if needed)deployProxyhas not been run before for the Directory because we are predicting the NEXT contract address with that address, not the SECOND!deployProxyagain, the default settings fordeployProxywill not redeploy the implementation unless it's changed or the cache is missing, instead just deploying the proxy itself using the next contract address as our deployment scripts expect. Therefore, subsequent deployments will succeed.To fix this, we need to ensure that the directory deployment address that is predicted to be used for deploying the proxy is EXACTLY the one that is actually used. Doing so will require refactoring the deployment scripts to either 1) manually deploy the implementation and proxy separately or 2) utilize the
redeployImplementationparameter fordeployProxy().We may also want to integrate with OZ Defender futher and use their relays for deployment so that we can use the
saltparameter fordeployProxy().