Skip to content

[pull] develop from tronprotocol:develop#150

Merged
pull[bot] merged 6 commits into
All-Blockchains:developfrom
tronprotocol:develop
May 8, 2026
Merged

[pull] develop from tronprotocol:develop#150
pull[bot] merged 6 commits into
All-Blockchains:developfrom
tronprotocol:develop

Conversation

@pull
Copy link
Copy Markdown

@pull pull Bot commented May 8, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

bladehan1 and others added 6 commits May 8, 2026 10:19
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 #6547
* feat(api): support int64_as_string parameter for GET requests (#6568)

Add an opt-in `int64_as_string` query parameter on TRON HTTP GET endpoints.
When set, int64/uint64 protobuf fields in the response are serialized as
quoted JSON strings to avoid precision loss in clients whose native number
type cannot safely represent integers above 2^53 - 1 (e.g. JavaScript).

Scope: GET only. POST is intentionally unsupported because reading the
request body in a centralized location (RateLimiterServlet.service or a
Filter) would consume request.getReader() and break downstream servlets
that read the body themselves. Most TRON query endpoints support both
GET and POST, so clients that need precision can use the GET form. POST-
only write endpoints return Transaction proto whose int64 fields would
break round-trip JsonFormat.merge if quoted, so they should not enable
this flag in the first place.

- JsonFormat: add INT64_AS_STRING ThreadLocal + setInt64AsString /
  clearInt64AsString / isInt64AsString helpers; split printFieldValue
  INT64/SINT64/SFIXED64 and UINT64/FIXED64 branches so they emit quoted
  strings only when the flag is set.
- Util: add INT64_AS_STRING constant + getInt64AsString (URL query,
  mirrors getVisible).
- RateLimiterServlet.service: set ThreadLocal from URL query on GET only;
  clear in finally so reused Tomcat threads do not leak state across
  requests.
- GetBurnTrx / GetPendingSize / GetTransactionCountByBlockNum: emit
  quoted int64 in their hand-built JSON responses when isInt64AsString
  is true.
- JsonFormatInt64AsStringTest: covers default behavior, int64 / uint64
  quoting, non-int64 fields unaffected, nested / map / boundary values
  (2^53 +/- 1, Long.MAX/MIN, -1), state cleanup (normal close, after
  exception, explicit clear), thread isolation, thread-reuse anti-pollution.

Backward compatibility: requests without int64_as_string=true produce
byte-identical responses to develop -- the new code paths are gated
entirely on the new flag.

Closes #6568.

* refactor(api): address review feedback on int64_as_string PR

Three small adjustments per review on PR #6699:

- GetTransactionCountByBlockNumServlet: add trailing newline at end of
  file to satisfy checkstyle.
- Util.getInt64AsString: align control flow with the existing
  Util.getVisible (single-return via local boolean, Boolean.valueOf
  instead of Boolean.parseBoolean). Functionally identical -- both
  return true only when the parameter value is "true" (case-insensitive).
- Util.INT64_AS_STRING -> Util.INT64_AS_STRING_PARAM: rename the public
  parameter-name constant to avoid potential confusion with the unrelated
  private ThreadLocal field of the same simple name in JsonFormat.
  The user-facing query parameter remains "int64_as_string" -- only the
  Java identifier changes.
@pull pull Bot locked and limited conversation to collaborators May 8, 2026
@pull pull Bot added the ⤵️ pull label May 8, 2026
@pull pull Bot merged commit 5ef7de6 into All-Blockchains:develop May 8, 2026
9 of 11 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants