eth, eth/fetcher, p2p: make tx arrival wait configurable via p2p.txarrivalwait - #2303
Draft
dkeysil wants to merge 1 commit into
Draft
eth, eth/fetcher, p2p: make tx arrival wait configurable via p2p.txarrivalwait#2303dkeysil wants to merge 1 commit into
dkeysil wants to merge 1 commit into
Conversation
…rivalwait The p2p.txarrivalwait config option and --txarrivalwait flag existed but were never wired into the transaction fetcher, which used the hardcoded 500ms txArriveTimeout since the v1.14.13 upstream merge. Plumb the value from p2p.Config through the eth handler into NewTxFetcher. A value of zero requests announced transactions immediately instead of waiting for a potential broadcast; negative values are clamped to zero.
dkeysil
force-pushed
the
dkeysil/configurable-txarrivalwait
branch
from
July 20, 2026 09:51
dbdf7af to
9332e19
Compare
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
p2p.txarrivalwaitconfig option (--txarrivalwaitflag) is parsed and documented but has no effect: since the geth v1.14.13 merge it is no longer passed into the transaction fetcher, which uses the hardcodedtxArriveTimeout(500ms) instead. This PR wires the configured value throughnode.Config→eth/backend→handlerConfig→NewTxFetcher, restoring the flag's documented behavior. The default is unchanged (500ms). A value of0requests announced transactions immediately; negative values clamp to 0.Why it matters: on a mainnet full node (~250 peers) we measured that a significant share of newly observed pending transactions (roughly 30–65% depending on peer topology; eth/68 senders direct-broadcast bodies only to √N peers, and blob/large txs are announce-only) arrive via hash announcement + fetch. Each of those currently waits up to 500ms before the body is even requested. With
txarrivalwait = "0s"theeth_fetcher_transaction_waiting_hashesgauge stays pinned at 0 and announced transactions are fetched after a single round-trip.Executed tests
go test -race ./eth/fetcher/— 144 tests pass, race clean.TestTransactionFetcherCustomArrivalWait(250ms wait honored),TestTransactionFetcherZeroArrivalWait(immediate scheduling),TestTransactionFetcherNegativeArrivalWait(clamped to 0),TestTxArrivalWaitConfig(TOML →fillTimeDurations→buildNode→node.Configplumbing, including the 500ms default).go test ./internal/cli/server/passes.txarrivalwait = "0s": fetch-path deliveries (eth_fetcher_transaction_replies_in) continued at full rate (~115 tx/s of ~169 tx/s total intake),waiting_hashesat 0, node stable, no peer-drop or bandwidth regressions observed.Rollout notes
Not consensus-affecting; no coordinated upgrade required. Backwards compatible: the default stays 500ms, so operators who never set the flag see no change. Operators who did set
txarrivalwaitshould note it has been silently ignored since v1.5.0 and will now take effect. In ≤v1.4.x the value was clamped to [100ms, 500ms]; this PR deliberately allows 0 so latency-sensitive operators can fetch announced transactions immediately, trading a modest increase in fetch-request traffic.