feat(api): improve request handling and validation

[halibobo1205]

User description

Summary

• Improve input handling and validation across HTTP and gRPC APIs.
• Reject unsupported requests earlier in processing.
• Reduce logging for invalid client input.

Compatibility

Some previously accepted inputs may now be rejected. Earlier validation may change error precedence and returned fields, using endpoint-specific error responses.

Block processing, P2P and consensus behavior remain unchanged apart from address-validation logging.

---

CodeAnt-AI Description

Limit oversized API inputs and reject transactions with multiple contracts

What Changed

• JSON parsing stops at 100,000 tokens, including large contract ABIs, and returns a clear limit error.
• URL-encoded forms that exceed the server’s parameter limit are rejected, including forms with repeated keys; JSON request bodies are unaffected.
• Transaction requests with multiple contracts receive validation errors instead of proceeding through creation, broadcast, shielded hash, or signing and approval checks. Common transaction creation also reports when no contract is supplied.

Impact

✅ Bounded parsing for oversized JSON requests
✅ Rejected forms above the parameter limit
✅ Clear validation errors for multi-contract transactions

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Incremental review completed	f17a200	Oct 12, 2026 · 06:04	06:05
✅ Reviewed your PR	05a422e	Oct 10, 2026 · 10:27	10:34

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-12T06:10:19.746212Z	f17a200	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[codeant-ai]

CodeAnt Nitpicks

2 code suggestions

1. The address is a 21-byte array here, but this log reports 42 as the required byte length, misleading anyone diagnosing invalid addresses.

Incorrect variable usage · common/src/main/java/org/tron/common/utils/DecodeUtil.java:21

---

2. checkFormPairs counts every &, including empty segments that UrlEncoded.decodeUtf8To ignores, so forms with few real fields can be rejected over the limit.

Incorrect condition logic · framework/src/main/java/org/tron/core/services/http/Util.java:742-748

[codeant-ai]

CodeAnt PR Risk: Low Risk

• The PR appears safe to merge; the transaction contract-count checks are applied across the shown broadcast, signing, approval, and shielded-transaction paths.
• Tests cover multiple-contract rejection and JSON token limits at, below, and above the configured boundary, including oversized ABI inputs.

Assessed commit: f17a200ec232

[waynercheung]

[SHOULD] Please document the concrete client-visible changes under Compatibility:

• JsonFormat enforces a 100,000-token budget per parsed document, including the ABI strings parsed by deploycontract and JSON-RPC buildTransaction.
• Form-encoded bodies have a fixed 1,000-entry limit, including repeated keys.
• Multi-contract requests are rejected earlier. Some HTTP arrays containing a valid contract and an unparseable or untyped contract previously had the latter silently dropped. Rejected multi-contract sign-weight/approval replies omit transaction. When rejection happens in packTransaction, HTTP broadcasttransaction returns an empty txid.
• gRPC createCommonTransaction now returns CONTRACT_VALIDATE_ERROR for zero or multiple contracts, instead of failing on an empty list or using only the first contract.
• Wallet.broadcastTransaction checks the contract count before the expiration check and before Manager's cryptographic signature/permission validation, which can change error precedence. Its existing signature-length check still runs first.

I verified f17a200 locally with JDK 17: all 176 selected tests and framework Checkstyle pass. The build, coverage, style and smoke checks also pass on CI; submit-gradle fails because of its own JDK setup. The consensus validation rules and Manager's existing error message are unchanged, so no hard fork is required.

[NIT] DecodeUtil.java:21 reports 42 as the expected byte length; please log ADDRESS_SIZE / 2 (21 bytes). If the shielded servlet re-wrap stays, a short comment explaining that clientMessage matches the exact exception class would help.

[waynercheung]

[SHOULD] This counts every &, including empty segments that UrlEncoded.decodeUtf8To ignores. For example, 1,000 k=v entries followed by a trailing & decode to exactly 1,000 parameters but are rejected here. Please count only non-empty segments (still counting repeated keys), and add tests for leading, trailing and consecutive &.

[waynercheung]

[DISCUSS] This test keeps the existing internal server error response when packTransaction returns null after a ParseException. Is keeping that response intentional for compatibility? If not, returning the parse error would avoid the null dereference in the servlets and give a clear validation error. This behavior predates the PR, so a follow-up is fine.