Feat/merge 4.8.1.1#131
Conversation
…,version code:18636 (tronprotocol#6542)
New workflows: - pr-build.yml: multi-OS build matrix (macOS, Ubuntu, RockyLinux, Debian11) and changed-line/overall coverage gate - pr-check.yml: PR title/body lint + Checkstyle - pr-reviewer.yml: scope-based reviewer auto-assignment - pr-cancel.yml: cancel in-progress runs when PR is closed unmerged - system-test.yml: spin up FullNode and run the system-test suite Existing workflows: - codeql.yml: bump to v4/v5 actions, switch to manual build-mode with JDK 8, add paths-ignore for docs-only changes - math-check.yml: bump checkout/upload-artifact/github-script versions
…ersion code:18643
* fix readme typo and format
Removed 4 config files from framework/src/main/resources that were not referenced anywhere in the codebase: - config-backup.conf: no references - config-beta.conf: no references - config-test-net.conf: no references - config-localtest.conf: only used in tests, shadowed by src/test/resources/config-localtest.conf on the test classpath
…ronprotocol#6586) * test: add dual DB engine (LevelDB + RocksDB) test coverage
Changes: - Add a registration status check to prevent duplicate initialization during CI test runs. - Throw TronError on actuator instantiation failures to improve error visibility and debugging. - Narrow package scanning from "org.tron" to "org.tron.core.actuator" to reduce reflection overhead and speed up registration. - Remove JVM args for CI test to avoid JDK8 G1 GC bugs and Evacuation Pause failures. - Optimize console output to prevent test OOM for CI - Adjust memory and parallelism settings - Exclude dnsjava InetAddressResolverProvider
…ation test TronError extends Error, not Exception, so use Throwable to ensure worker thread failures are properly captured. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix(config): remove redundant JSON-RPC config fields and consolidate parameter binding Remove maxBlockFilterNum, maxAddressSize, and maxRequestTimeout from NodeConfig/CommonParameter since they were superseded by the jsonRpcMaxBatchSize/jsonRpcMaxResponseSize parameters. Consolidate the config binding path so all JSON-RPC size limits flow through a single reference.conf entry, and clean up stale test-config fixtures. * fix bug of NodeConfigTest * remove allowShieldedTransactionApi from reference.conf * add testcase of external.ip is null * change comment * fix the bug of --es and 7 failed testcases
…onprotocol#6760) Pre-3.0.0(The previous event-plugin public release is 2.2.0) event-plugin builds still link against com.alibaba.fastjson, which was removed from java-tron in tronprotocol#6701. When such a plugin is loaded, the NoClassDefFoundError surfaces inside the plugin's own worker thread and is swallowed by its catch(Throwable) handler. The node keeps running while silently dropping every trigger, leaving operators with no signal that the event subscription is broken. Enforce a minimum Plugin-Version at startup in EventPluginLoader.startPlugin using pf4j's VersionManager (semver). When the descriptor version is below 3.0.0, log a clear upgrade hint and return false; the existing call chain in Manager.startEventSubscribing wraps that into TronError(EVENT_SUBSCRIBE_INIT) and aborts node startup instead of silently degrading.
…rs (tronprotocol#6761) - Add `rate.limiter.apiNonBlocking` switch (default false). When off, callers wait for a permit; when on, they reject immediately and shed load. - Wire the switch through `RateLimiterConfig` → `Args` → `CommonParameter`; update `reference.conf` / `config.conf`. - Add blocking `acquire()` paths on `IRateLimiter`, `GlobalRateLimiter`, and `QpsStrategy` / `IPQpsStrategy` / `GlobalPreemptibleStrategy`. Only the semaphore-based strategy is bounded (2s); the QPS-based paths use unbounded Guava `RateLimiter.acquire()`. - Introduce `acquirePermit()` dispatcher (default method on `IRateLimiter`; static on `GlobalRateLimiter`) that picks blocking vs non-blocking based on the switch. - Swap `tryAcquire` → `acquirePermit` at the `RateLimiterServlet` and `RateLimiterInterceptor` call sites; preserve per-endpoint-before-global ordering to avoid consuming global quota on per-endpoint rejection. - Extract `loadIpLimiter()` in `GlobalRateLimiter` and `loadLimiter()` in `IPQpsStrategy` to share cache+exception handling between `tryAcquire` and `acquire`. - Add unit tests covering dispatcher routing (both directions), acquire IP-before-global ordering, and IP-loader-failure fail-closed behaviour.
…onprotocol#6791) - P2pEventHandlerImpl.processException's switch did not include the BLOCK_MERKLE_ERROR type introduced by PR tronprotocol#6716. The new type fell through to the default branch, so peers whose blocks failed merkle root validation were disconnected with ReasonCode.UNKNOWN instead of BAD_BLOCK, missing the bad-peer ban window in PeerConnection.processDisconnect. - Add the case alongside BAD_BLOCK and BLOCK_SIGN_INVALID so the disconnect reason is reported as BAD_BLOCK end-to-end. - Rename the two enum constants for naming consistency: BLOCK_SIGN_ERROR -> BLOCK_SIGN_INVALID, BLOCK_MERKLE_ERROR -> BLOCK_MERKLE_INVALID, and reword their descriptions to 'sign failed' / 'merkle failed' to match the imperative style used by the other nearby enum entries. All call sites updated. - Add two regression tests in P2pEventHandlerImplTest: one pins BLOCK_MERKLE_INVALID -> BAD_BLOCK (the actual fix); the other pins BLOCK_SIGN_INVALID -> BAD_BLOCK so a future switch refactor cannot silently drop either back to UNKNOWN.
…ocol#6777) - Manager.switchFork now re-validates each replayed block's witness signature before applying. The witness account's permission can change between forks (via permission-update transactions), so a signature that was valid on the original chain may no longer be valid on the replay path. - Use `if (!validateSignature(...)) throw new ValidateSignatureException` rather than discarding the boolean return: validateSignature only throws on malformed signature bytes; an attacker-supplied valid-format signature with a wrong-signer address returns false. Discarding the return would let that attack through. - The existing switchFork catch list already includes ValidateSignatureException, so the new throw is wired into the existing switchback path with no additional handling. - Add three BlockCapsule.validateSignature contract tests pinning the two failure modes the fix relies on: signer-mismatch returns false, signer-match returns true, and a 65-byte malformed signature throws ValidateSignatureException.
…ronprotocol#6796) Initialize multiAddresses from ownerAddressSet so that getVerifyTxs still forces re-verification of an owner's later txs even after the owner's permission-change tx has been packed and is no longer present in pendingTransactions. Main changes: - Manager.getVerifyTxs: seed multiAddresses with ownerAddressSet to cover the case where a permission-change tx has been consumed but ownerAddressSet still retains the owner (kept alive by in-flight txs in pushTransactionQueue / rePushTransactions via filterOwnerAddress). - ManagerTest: add getVerifyTxsSkipsBlockWhenPermissionTxAlreadyConsumed reproducing the bypass — pending contains only B (transfer, old sig, isVerified=true), ownerAddressSet contains the owner, block contains only B without the permission-change tx. Assertion checks B is placed in the re-verify list instead of being short-circuited via setVerified.
…col#6780) * fix(vm): canonicalize ModExp zero modulus output (TIP-871) * func(vm): remove account name for history block hash contract * test(db): align BlockHashHistory account name assertion
* feat(net): normalize inbound messages * perf(net): skip wire-byte rewrite when sanitize is a no-op
|
Skipping CodeAnt AI review — this PR changes more than 100 files, which usually means a migration, codemod, or vendored drop. Line-level review on diffs this large produces duplicate findings on the same rewrite pattern and drowns out anything that actually matters. If you still want a review, comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6c5926a6b9
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| CommonParameter parameter = CommonParameter.getInstance(); | ||
|
|
||
| // Transport IOException from readBody propagates as HTTP 500 (genuine IO failure). | ||
| byte[] body = readBody(req.getInputStream()); |
There was a problem hiding this comment.
Enforce the JSON-RPC request size limit
When JSON-RPC is enabled, this path reads the entire POST body into memory before parsing and never checks CommonParameter.jsonRpcMaxMessageSize (configured in node.jsonrpc.maxMessageSize, default 4 MB). A client can therefore send an arbitrarily large body to the JSON-RPC endpoint, bypassing the configured request limit and forcing the node to buffer and parse it, unlike the other HTTP body-size checks.
Useful? React with 👍 / 👎.
| batchResult.add(buildErrorNode(JsonRpcError.RESPONSE_TOO_LARGE, | ||
| "Response exceeds the limit of " + maxResponseSize + " bytes", | ||
| subRequest.get("id"))); |
There was a problem hiding this comment.
Keep batch overflow errors within the response cap
After the first batch response exceeds maxResponseSize, every remaining request with an id appends another RESPONSE_TOO_LARGE object without updating or checking accumulatedSize. For a large batch near the configured response limit, the final serialized array can grow well beyond node.jsonrpc.maxResponseSize, so the response-size cap is not actually enforced for overflow batches.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1afe68ceb5
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| VERSION_4_8_1(34, 1596780000000L, 80), | ||
| VERSION_4_8_2(35, 1596780000000L, 80); | ||
| VERSION_4_8_1_1(35, 1596780000000L, 70), | ||
| VERSION_4_8_2(36, 1596780000000L, 80); |
There was a problem hiding this comment.
Preserve the 4.8.2 fork version value
Because VERSION_4_8_2 was already value 35 in the parent commit, moving it to 36 makes any stored version-35 fork stats or previously produced version-35 blocks map to VERSION_4_8_1_1 instead. On a chain that has already observed/activated 4.8.2 at 35, pass(VERSION_4_8_2) becomes false until a new round of 36 votes, while pass(VERSION_4_8_1_1) can become true from the old 4.8.2 votes, enabling these CPU-time behavior changes at the wrong fork and causing this release to produce a different block version for an existing fork; keep the existing 4.8.2 numeric value stable or add an explicit migration for stored fork stats.
Useful? React with 👍 / 👎.
1afe68c to
4ca8927
Compare
4ca8927 to
4bc641e
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4bc641e9df
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (baseLen == 0 && modLen == 0 && expLen > UPPER_BOUND) { | ||
| MUtil.checkCPUTimeForModExp(); |
There was a problem hiding this comment.
Honor Osaka's ModExp length rejection first
When ALLOW_TVM_OSAKA is enabled after the 4.8.2 fork, VERSION_4_8_1_1 will also have passed, so calldata with baseLen == 0, modLen == 0, and expLen > 1024 now throws OutOfTimeException here before reaching the Osaka branch that should return Pair.of(false, EMPTY_BYTE_ARRAY) for oversized lengths. That changes the TIP-7823/Osaka behavior for this input from a failed precompile call to an exceptional CPU-time abort; move the Osaka length rejection ahead of this legacy timeout check or skip the timeout when Osaka is active.
Useful? React with 👍 / 👎.
What does this PR do?
Why are these changes required?
This PR has been tested by:
Follow up
Extra details