We are signing and sending a pretty big number of transactions to main net but almost everyday some of them are not being broadcasted to main net, I cannot see them in pending pool. This happens for an interval of 20-30 minutes then it works fine.
Nonces are being managed correctly, gas price is being read from a gas tracker on top of which we add 10%, there is a delay of 5 seconds between the sending of transaction.
Is there any limitation for a “from” address which will allow only a specific number of transactions to be send in a time interval? Or any other limitations except API limits (which we don’t exceed)?
The result are lots of “Transaction was not mined within 750 seconds” errors, for which we have to wait a while until resend them, to make sure they have not been mined and avoid duplication.
Hey @EsoxLucius, and welcome to the Infura community!
Are you using WebSockets or HTTPS to send these transactions? For HTTPS, we have a rate limit of 10 req/sec and 100,000 req/day (which can be bumped up if you sign up for a higher tier if necessary). Our WebSockets have a limit of 1000 log subscriptions at a time. If you’re below these limits, let us know and we’ll do some more digging to figure out what’s going on!
Thank you for your answer.
We are sending 1 transaction each 5 seconds using HTTPS and there’s no issues with the daily API limits, our plan is a paid one.
It’s not happening all the time, usually the transactions are being broadcasted, it’s just some times maybe for 30 minutes they all fail.
Are you using web3, by chance? If so, they have a default transactionPollingTimeout, which is 750 seconds. This is used only with web3's HTTP provider, however, so if WebSockets are an option, you can try switching to a Websocket provider to avoid that timeout. This issue on the Truffle GitHub may give you some additional context if you want to try that out!
Now I see the information I provided was too few…
Yes, we are using web3js. Because of the transactionPollingTimeout, will the HTTPS connection be closed thus transaction won’t be broadcasted while websocket will still stay alive at least until any close connection event occurs?
Hey JB - that’s right. We do close websockets if they go without being used for a certain amount of time to keep things clear, but it sounds like you wouldn’t be running into that issue.
Hello,
I am back…after I changed the signing process so the transactions are being sent to the blockchain using a websocket connection, we still encounter this issue - not at the same scale as using HTTP provider, still failing too much.
Also the connection has been closed few times, when there were some “on the fly” transactions.
Again, I am using web3js (v1.2.5) with this configuration:
Hmm, interesting. We’ve seen this happen once in a while - have you checked your gas price? If it’s working intermittently, your gas price may just be too low. You can try sending it through with the higher gas price on a testnet and if it goes through, that’s your issue and you just need to increase your gas price on mainnet! Otherwise, let us know and we’ll continue to dig.
I have this issue sometimes mostly when volatility of ETH price is high. This isn’t because of the gas price because I can re-send the same transaction with same gas price successfully otherwise web3 will raise “gas price too low” error.
Got it. Unfortunately, when the volatility of the ETH price is high, there isn’t much we can do on our side. One thing you can do to make sure none of your transactions get missed is to make sure you have a failsafe set up so if the connection is closed, you’ll automatically reopen a connection and retry sending the previous txn.