-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Futures timed out with transactions unconfirmed after maximum fee bumps #735
Comments
Hey @racket2000, if you rerun the deployment without changes and using the same deployment id (the default of The deployed addresses, after the second run, should be stored under |
Hello, thank you very much for getting back with me. When I rerun the deployment, I receive an error: However, the contract has been published accordingly to Polygon Scan I am not too sure how to solve this, it seems to be getting this error from my blockchain node provider. |
It suggests Ignition is trying to send a transaction where the nonce has already been used and confirmed - which would be an Ignition bug. Is the deployment you are trying to run open source, to help us try and reproduce this? |
Hello, thank you for the assistance. My deployment is not open-sourced -- it is an extremely basic Hello World contract for reading/writing a message into a variable. I am using the following parameters in my ignition: { I believe that the maxFeeBumps parameter may be causing the issue, since I assume it is creating multiple transactions with higher fees under the hood. When I did not include these parameters, the contract would fail to deploy due to a low-estimated gas fee. (The default settings have not worked for deploying on Polygon Mainnet.) It took a contract multiple hours to end up being deployed on the network when I did not specify the above parameters. |
Hey @racket2000, so there are two issues here:
We will investigate |
Not to pile on, but having similar issues with Polygon (mainnet) network. It simply refuses to deploy contracts. I'm guessing my issue is cursorily related to these as well: For the record, I can deploy to BSC, Base, ETH (I'm guessing all L1s?) just fine. However, when it comes to Polygon specifically it is horribly inconsistent. In the context of Polygon, I've tried multiple RPCs from:
Also, for the record, I've tried old school hre.viem.deployContract, and receive errors as well. So, my guess is it goes to some core HH feature rather than simply Ignition. I've attached a trimmed version of my Ignition output. Anyway, just a bit more info. |
Thanks for the information and Ignition output. For polygon specifically, the gas fee estimation heuristic that gets used in both Hardhat and Ignition is giving poor results (Polygon is just too different). Until we understand Polygon gas fee calculations better we are going to revert to pre-1559 transactions on Polygon, which is giving us far more predictable results in manual testing. You can follow along with that PR here: #740, it will be shipped in the next release. |
I've investigated this issue, but I've been unable to reproduce this on the newest Ignition release (0.15.2). There may be an underlying bug still, but since the case to trigger it is an edge case under normal circumstances (transactions taking extreme amounts of time to confirm repeatedly), I'm going to close this issue for now. This specific case was fixed as a result of us fixing Polygon transactions in general in release 0.15.2. If the bug pops up again, we can reopen and reevaluate. |
I am receiving this error message when I try to deploy my contract on Polygon Mainnet:
Futures timed out with transactions unconfirmed after maximum fee bumps
However, after several minutes, the contract ends up being deployed. I determined this by looking up my Account address which is used for deployment on PolygonScan.
I would like to print out the Contract Address in the Console, as it is a part of a developer tutorial.
Is there anyway to override the maximum gas fee that is used for contract deployment? I saw associated issues regarding this, but I am not sure if a fix has been implemented yet.
The text was updated successfully, but these errors were encountered: