because of uncertainty in the network congestion, sometimes, creation process will timeout.
There is no way to get any transaction hash to identify any of the 2 transactions that were sent.
And also no way to get the proxy contract address as well.
Or is there a way out of this situation?
The documentation lacks alot of api details for developers to self help.
Any help here would be appreciated.
The proxy contract pointing to the logic contract along with calling the initialization logic.
Whilst we could use npx oz add and npx oz push to deploy the logic contract. npx oz deploy still has two transactions, deploying the ProxyAdmin and deploying the proxy contract + calling the initialization logic.
I am not sure if there is a way to break this up so that we have a single transaction per step.
Assuming you have deployed, we can get our addresses from <network_name>.json and use Etherscan to see the transactions from our address. The proxy should be verified on mainnet. You can also verify your logic contract to make it easier to identify.
Thanks for the suggestion. However, manual check is not really the criteria here as we are doing programmatic deployment in js.
Self recovery or breaking the deployment into 2 callable steps would be ideal since transaction hash can be returned asynchronously and we dont have to wait for a long time before we get an error.
With the transaction hash returned for the 2 steps, we will be able to check as and when is needed.
// Create a proxy for the contract
const proxy = await myProject.createProxy(MyContract);
the web3 provider is using Infura.
So If createProxy is called repeatedly,
usually a ‘nonce too low’ or ‘known transaction’ error occur.
Sometimes for network congestion it will be ‘taking longer than 750 seconds’ error.
For ‘nonce too low’ or ‘known transaction’ error, I believe is because a nonce issue.
Because it’s a 2 step process wrapped in one function call, there’s no way we can design the code to fail or retry gracefully. Everything becomes encapsulated.
For ‘taking longer than 750 seconds’ error, we don’t get any transactionHash in return for us to monitor.
All these limitations restrict what we can do to scale and fail reliably.
We were thinking of using queues to process and retry.
Are you able to provide a bit more detail about what you are building?
Are you creating upgradeable proxies all pointing to the one logic contract?
Are you using a ProxyAdmin? If so are you using one ProxyAdmin or one per proxy?
Which project type are you creating, SimpleProject, ProxyAdminProject or AppProject?
I was using SimpleProject since the code was available somewhere. No idea if I copied from the forum.
Every time I will need to create a brand new set of upgradable contract. Both proxy and logic are new instances.
I was not able to find any information on the other projects. It is a bit tough to navigate and see what are all the available options from the topics menu. And the part which mentioned the 3 projects did not have an immediate hyperlink to the mentioned page. It just says Upgrades section. I won’t know what’s that. I see a few Upgrades topics here and there. Without and overview, it’s very confusing.
Thanks for the reply.
I think the fastest way for me and other developers to pickup is to be able to find a url link to a traditional developer documentation on these project objects. Currently, I have no idea what’s the difference between SimpleProject or ProxyAdminProject. Why is it called a Project? What’s their methods calls/params, what do they do?
I think the main issue could be a lack of a central location to learn specific topics.
It could be a really good self help.
Could it be due to v2.6 libraries not using CREATE2 opcode that results in nonce issues?
Also are there sample outputs for v2.8 libraries that has creation calls that could return proxy contract addresses asynchronously?
@skybach I’m really sorry about the lack of documentation around using upgrades programmatically from JavaScript. The existing JavaScript interface kind of evolved as the internals of the CLI, and was not optimized to be a user-facing API. This is definitely a weak point of the library, which is why we’re currently working on a redesign, announced in the Q2 Roadmap. Unfortunately I can’t share a timeline for it yet, but the project is likely going to extend into Q3.
If you’re in a position in which you need to use the current library, perhaps you’d find the example in the repo useful.
@skybach We’ve released the new Upgrades plugins for Truffle and Buidler that are designed for programmatically deploying proxies and performing upgrades, and are designed to work better in a congested network. Even if any of the transactions time out, rerunning your script should pick up where it left of and wait for any pending transactions instead of resending them.
Take a look at the announcement and repository for this new project and let us know what you think!