feat(loadtest): --sync-txs for eth_sendRawTransactionSync, plus two runner fixes

[minhd-vu]

Two independent changes, one commit each — the bug fixes first, so they can be split out or cherry-picked if you'd rather they land on their own.

1. fix(loadtest): two bugs on the plain send path

Both pre-date this branch and reproduce without --sync-txs. I hit them while testing the feature below.

Nil gas prices panicked the run. getSuggestedGasPrices returns the cached price and tip cap from six early returns, three of which are RPC-failure paths that run before the cache is first written. On a first-call failure they returned (nil, nil), and configureTransactOpts dereferences the result (tops.GasTipCap.Cmp(...)), so one failed eth_feeHistory or eth_maxPriorityFeePerGas killed the run with a stack trace. suggestMaxFeePerGas likewise returns nil when HeaderByNumber or FeeHistory fails, and that nil was being cached and handed out.

Those returns now go through a cachedPrices helper that substitutes zero for an unset value, and a nil from suggestMaxFeePerGas falls back instead of being cached. The RPC error is already logged at each site so the cause stays visible, and a zero-priced transaction is rejected by the node and recorded as a send error — the same outcome account.go already settles for, and better than losing the run. The helper returns copies: these values outlive the lock and every sending goroutine holds one, so handing out the cached pointers would make any in-place arithmetic by a future caller a silent race on shared state.

--rate-limit -1 hung the run permanently. waitForFinalBlock built its limiter straight from --rate-limit, without the non-positive check the main loop applies ~1000 lines earlier. A negative rate.Limit has tokens that never replenish: the first nonce check took the initial token and every later one blocked on Wait forever, so wg.Wait never returned. Any run with rate limiting disabled and more than one account hung after sending — not a slow wait, an unbounded one. The retry loop also used a bare time.Sleep(5s) × 30 retries, so Ctrl+C was ignored for up to 150 seconds.

Now: no limiter when the rate limit is non-positive, the rl != nil guard already used at the other wait site, time.NewTimer + select on ctx.Done(), and a cancellation check per retry.

Verified against a fake node: the feeHistory-less case exits 0 with Unable to get fee history logged instead of panicking, and the --rate-limit -1 case exits 0.3s after SIGINT with debug logs confirming it was inside the retry loop.

2. feat(loadtest): --sync-txs for eth_sendRawTransactionSync

Sends via EIP-7966 eth_sendRawTransactionSync, which returns when the node has a receipt rather than when the transaction is accepted — so on a preconfirming chain it measures preconfirmation latency directly. Implemented as a send-path option alongside --private-txs rather than a mode, so it composes with every workload that broadcasts raw: transaction, blob, contract-call, recall.

Where bor and the EIP disagree, this follows bor (internal/ethapi/api.go):

	EIP-7966	bor	this PR
timeout encoding	integer	*hexutil.Uint64 → hex string only	hex by default, --sync-tx-timeout-int for the integer form
error codes	4, 5, 6	only 4; refusals return -38010/-38011/-38013/-38014/-38026	both sets classified
speculative marker	none defined	"preconfirmation": true, null blockHash	marker is authoritative; block-fields fallback otherwise
default wait	2s recommended	20s, clamps above --rpc.txsync.maxtimeout	documented, parameter omitted when unset

The encoding one matters most: my first cut sent an integer per the spec text and would have failed against every bor node. Proven both ways against a bor-accurate fake — hex gives 30 receipts, integer gives 8/8 cannot unmarshal non-string into Go value of type hexutil.Uint64.

A SyncTracker on mode.Dependencies logs a summary at run end: receipts split speculative/canonical, reverted, no_status, timeouts, queued, nonce_gaps, rejected, and call latency percentiles.

This changes what the latency numbers mean — recorded request duration becomes time-to-receipt rather than time-to-accept, so --concurrency is the number of transactions in flight. Called out in the usage docs.

Testing

24 new tests across loadtest/mode, loadtest/config and loadtest; -race clean, full suite green, go vet and golangci-lint clean, make gen-doc run.

End-to-end against a fake bor implementing the sync method: submitted:50 receipts:30 speculative:20 canonical:10 timeouts:10 nonce_gaps:10 other_errors:0.

Not tested against a real node. Everything here was verified against fakes built from bor's source and its own test assertions — no run against a live bor with the preconfirmation pipeline enabled, which is the configuration the speculative path actually needs (that pipeline is still unmerged, bor#2373). Against stock bor speculative will read zero, because it requires both a block number and hash before answering.

🤖 Generated with Claude Code