fix(jsonrpc): correct TransactionResult.nonce per JSON-RPC spec#6709
fix(jsonrpc): correct TransactionResult.nonce per JSON-RPC spec#6709waynercheung wants to merge 1 commit intotronprotocol:developfrom
Conversation
waynercheung
changed the title
Per ethereum/execution-apis, TransactionInfo.nonce is `uint` (QUANTITY) and must match `^0x(0|[1-9a-f][0-9a-f]*)$`. java-tron emitted the field as `0x0000000000000000` via `ByteArray.toJsonHex(new byte[8])`, which violates the pattern. Both `TransactionResult` constructors now emit `"0x0"`. Block.nonce is intentionally left at `0x0000000000000000` because the Block schema defines it as `bytes8`, so that value is already compliant and shortening it would break conformance. Closes tronprotocol#6547
waynercheung
force-pushed
the
fix/jsonrpc-tx-info-quantity-format-6547
branch
from
cc50549 to
ef27b6d
Compare
waynercheung
changed the title
|
After review discussion, the scope of this PR has been narrowed to only the The branch has been force-pushed to a single minimal commit. Earlier inline comments on the now-removed changes are no longer applicable; please re-review the latest state. |
| byte[] txId = capsule.getTransactionId().getBytes(); | ||
| hash = ByteArray.toJsonHex(txId); | ||
| nonce = ByteArray.toJsonHex(new byte[8]); // no value | ||
| nonce = QUANTITY_ZERO; // no value |
There was a problem hiding this comment.
[NIT] Drop or rewrite the stale // no value comment on nonce
The // no value comment on both nonce = QUANTITY_ZERO lines describes the old new byte[8] placeholder. After this PR the value is a real spec-compliant zero, not a placeholder, so the comment is misleading.
Suggestion: drop it, or replace with // TRON has no Ethereum nonce, always 0.
4 participants
What this PR does
Corrects the
noncefield inTransactionResult, the response body shared byeth_getTransactionByHash,eth_getTransactionByBlockHashAndIndex,eth_getTransactionByBlockNumberAndIndex, and the full-tx mode ofeth_getBlockByHash/eth_getBlockByNumber.Closes #6547.
Why
Per
ethereum/execution-apis:TransactionInfo.nonceisuint(QUANTITY), pattern^0x(0|[1-9a-f][0-9a-f]*)$- no leading zeros; zero is0x0.java-tron's
TransactionResultpreviously emittedByteArray.toJsonHex(new byte[8])->"0x0000000000000000"(16 hex chars), which violates the pattern.What changes
nonceTransactionResultconstructors0x00000000000000000x0Why
Block.nonceis intentionally NOT changedBlock.nonceisbytes8per the spec (pattern^0x[0-9a-f]{16}$), so the existing0x0000000000000000is already compliant. Shortening it to0x0would break conformance with the bytes8 length requirement.BlockResult.nonceis therefore left untouched and existingJsonrpcServiceTestassertions on it ("0x0000000000000000") remain valid.Compatibility
This PR makes a minimal, surgical change: only the
nonceliteral value is modified. All other fields inTransactionResultretain their existing serialization, preserving byte-for-byte compatibility with current production responses.The numeric semantics of
nonceare unchanged (Long.parseLongof either value yields0); only the string representation tightens to the spec-compliant form.Tests
TransactionResultTestis updated to:nonce == "0x0"in both test methods (covering bothTransactionResultconstructors).nonceagainst the schema regex^0x(0|[1-9a-f][0-9a-f]*)$via a smallassertQuantityhelper, so any future regression that re-introduces a leading-zero form will fail the test.Pre-submit checklist
noncereturned byeth_getTransactionByHashis non-compliant #6547), 2 files changed