fix(rpc): null pending fields + zero-address coinbase in getTransactionByHash#702
Merged
Merged
Conversation
…onByHash Two follow-ups on the EVM-shape conversion shipped in #692, both flagged by review after merge: 1. Pending / not-yet-included txs now return null for blockHash, blockNumber, and transactionIndex instead of genesis-looking defaults (block 0, empty string, "0x0"). EIP-1474 clients rely on these three being null to distinguish a mined tx at genesis from one still in the mempool. Pre-fix, ethers.js would happily treat any pending tx as "mined at block 0" and start polling for confirmations against the genesis block. 2. Coinbase / system-emitted txs ("COINBASE" sentinel sender, or empty) now serialize from as the zero address. Receipts already do this; the tx-by-hash path was emitting "0xCOINBASE" or "0x" verbatim, which crashes the same address parsers the original fix tried to unblock. Skipped the third review point — branching tx_type/maxFeePerGas/v on the original TxEnvelope variant — because every EVM tx on Sentrix currently flows through the EIP-1559 base-fee pipeline (cast/forge/ Hyperlane all send type 0x2), so the hard-coded "0x2" matches actual execution semantics. Worth revisiting if/when legacy or 2930 envelopes start landing.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR refines how pending (mempool) transactions are represented in JSON-RPC responses. The Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
satyakwok
added a commit
that referenced
this pull request
May 21, 2026
github-actions Bot
pushed a commit
that referenced
this pull request
May 21, 2026
* fix(rpc): eth_getTransactionCount + eth_call + logsBloom length Three discrete chain-RPC fixes bundled because they share one cause (strict-but-non-spec behavior breaking off-the-shelf EVM agents). All discovered together standing up the Hyperlane relayer for the Base Sepolia ↔ Sentrix Testnet bridge (audit fix H-4). 1) eth_getTransactionCount accepts any block tag. Relayer + ethers + viem all pin nonce queries to a recent past block. A stale nonce is self-correcting (chain rejects wrong-nonce tx, caller retries) so this method serves current nonce regardless of block tag. 2) eth_call accepts any block tag. Same pattern: Hyperlane queries Mailbox.delivered(msgId) and recipientIsm(addr) at past blocks. Returns current-state. The strict gate stays on eth_getBalance / eth_getCode / eth_getStorageAt where wrong = wrong protocol decision. 3) Empty logsBloom is now actually 256 bytes (Ethereum spec). The EMPTY_LOGS_BLOOM const was 304 bytes (608 hex chars) because of an off-by-one in the original hand-typed string. The doc comment said 256 but the literal was 304. ethers' fee-oracle middleware strict-parses Block.logsBloom — Hyperlane gas estimation SerdeJson'd on this with "invalid length 608, expected 256 bytes" before any process() tx could be submitted. Bumps workspace 2.2.13 -> 2.2.14. * docs(changelog): add 2.2.14 entry — five RPC compat fixes 2.2.14 went live on mainnet 2026-05-21 17:02 UTC carrying PRs #692/#696/#702/#703/#704. Document the five fixes + flag that the eth_call + logsBloom fixes on this branch are scheduled for 2.2.15.
github-actions Bot
pushed a commit
that referenced
this pull request
May 22, 2026
…bytes (#707) * fix(rpc): eth_getTransactionCount + eth_call + logsBloom length Three discrete chain-RPC fixes bundled because they share one cause (strict-but-non-spec behavior breaking off-the-shelf EVM agents). All discovered together standing up the Hyperlane relayer for the Base Sepolia ↔ Sentrix Testnet bridge (audit fix H-4). 1) eth_getTransactionCount accepts any block tag. Relayer + ethers + viem all pin nonce queries to a recent past block. A stale nonce is self-correcting (chain rejects wrong-nonce tx, caller retries) so this method serves current nonce regardless of block tag. 2) eth_call accepts any block tag. Same pattern: Hyperlane queries Mailbox.delivered(msgId) and recipientIsm(addr) at past blocks. Returns current-state. The strict gate stays on eth_getBalance / eth_getCode / eth_getStorageAt where wrong = wrong protocol decision. 3) Empty logsBloom is now actually 256 bytes (Ethereum spec). The EMPTY_LOGS_BLOOM const was 304 bytes (608 hex chars) because of an off-by-one in the original hand-typed string. The doc comment said 256 but the literal was 304. ethers' fee-oracle middleware strict-parses Block.logsBloom — Hyperlane gas estimation SerdeJson'd on this with "invalid length 608, expected 256 bytes" before any process() tx could be submitted. Bumps workspace 2.2.13 -> 2.2.14. * docs(changelog): add 2.2.14 entry — five RPC compat fixes 2.2.14 went live on mainnet 2026-05-21 17:02 UTC carrying PRs #692/#696/#702/#703/#704. Document the five fixes + flag that the eth_call + logsBloom fixes on this branch are scheduled for 2.2.15.
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
Two follow-ups on the EVM-shape conversion shipped in #692, both flagged by CodeRabbit after merge.
What changed
Pending / not-yet-included txs return null for
blockHash,blockNumber, andtransactionIndexinstead of genesis-looking defaults (block 0, empty string, "0x0"). EIP-1474 clients rely on null to distinguish a mined tx at genesis from one still in the mempool. Pre-fix, ethers.js would treat any pending tx as "mined at block 0" and poll genesis for confirmations.Coinbase / system-emitted txs (sentinel sender "COINBASE" or empty) now serialize
fromas the zero address. Receipts already do this; the tx-by-hash path was emitting"0xCOINBASE"or"0x"verbatim, which crashes the same address parsers fix(rpc): eth_getTransactionByHash returns EVM-standard JSON shape #692 tried to unblock.What's skipped
Third CodeRabbit point — branching
tx_type/maxFeePerGas/von the originalTxEnvelopevariant — is skipped. Every EVM tx on Sentrix currently flows through the EIP-1559 base-fee pipeline (cast / forge / Hyperlane all submit type 0x2), so the hard-coded values match actual execution semantics. Worth revisiting if/when legacy or 2930 envelopes start landing.Test plan
fromfor coinbase / reward txsSummary by CodeRabbit
Bug Fixes
nullfor block-related fields, providing clearer and more accurate transaction status information when transactions are not yet mined.