Transaction Hash Returned but Not Broadcasted Automatically

[J1a-wei]

Hi Geth Team,

I've encountered an issue where Geth returns a transaction hash after sending a transaction, but the transaction does not seem to be broadcasted to the network. As a result, the transaction only appears on the blockchain after manually broadcasting it using a block explorer.

• What might be causing Geth to return a transaction hash but not broadcast the transaction?
• Are there any configuration parameters that can be optimized to prevent this issue?

Geth version: v1.14.3

[dreamPerson0106]

This issue has been preview on the Pull Requests. To resolve, Contact the Ethereum support page to initiate a chat with the live agent on the chat button to get more information about your request via ETH Support Thanks for posting @J1a-wei

This seems like a scam. Please do not open the links of this comment.

[jwasinger]

Can you set the log level to trace (debug.vmodule("core/txpool=5") in the console), try again to resubmit, see if there is anything relevant in the logs (and post them here)?

[jwasinger]

Also, ensure that the transaction hash appears in the output of txpool.inspect and note which category (pending/queued) it falls into.

[J1a-wei]

Hi, @jwasinger ,

We are a node provider, and similar issues have occurred before. Currently, we are unsure how to debug this. Could you please explain the mechanism of the transaction pool and the possible situations that might arise?

Additionally, are there any optimization techniques we can use to improve the success rate of broadcasting transactions?

Thank you very much.

[jwasinger]

@J1a-wei so I assume this issue happens occasionally, and is not necessarily reproduceable on command?

I'm going to assume that the transactions in question are normal transactions, and not blob transactions (as these are not direct broadcasted).

When normal transactions are sent to the pool (regardless of local/remote origination), they are first validated:

• signature is correct and made by the sender account.
• transaction pays the minimum "intrinsic gas" necessary.
• transaction sender has enough funds to include this transaction, as well as others they may have already queued up.
• transaction nonce is above the nonce of the account in the pool. if there is another queued/pending transaction from the same account with a matching nonce already in the pool, the incoming transaction must pay more than the existing one. If it does, it bumps the existing transaction out of the pool and replaces it.

Transactions which pass this validation are considered "queued": the set of transactions which are not necessarily currently-executable (higher nonce than the current value for the sender).

Asynchronously, the pool will look for queued transactions that have become executable and move these to the "pending" set.

From there, these are direct-broadcasted to a random subset of the peers. The size of this subset is the square root of the peer set.

Given that you received no error from sending the transaction to the pool, it passed validation and was included in the queued set. Because it is able to be included reliably via a block explorer, I assume that it became executable, and eligible for broadcast.

Perhaps there are not enough peers in the direct-broadcast set to reliably propagate the transaction through the network. How many peers are connected when you experience the issue?

Note that to prevent spamming the network with additional traffic, Geth will not automatically re-broadcast transactions if they do not get included in the chain. This is functionality that you will have to build yourself.