Conversation
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…cout#14654) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…4761) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…#14764) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Victor Baranov <baranov.viktor.27@gmail.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Important Review skippedToo many files! This PR contains 148 files, which is 48 over the limit of 100. To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (148)
You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the application to version 11.3.1, introducing support for OP Stack Upgrade 20 (Super Root games, SystemConfig v4) and OP Stack post-exec transactions. It includes significant performance optimizations, such as caching public address tags, deduplicating on-demand token total supply fetchers, and introducing incremental consolidation for address and token counters. Additionally, it optimizes JSON RPC request grouping and local event broadcasting. The review feedback highlights a potential crash in optimism_view.ex due to the use of DateTime.from_unix!/1 on unvalidated on-chain data, suggesting a safer fallback using DateTime.from_unix/1 to prevent 500 errors.
| {:block_number, block_number} -> {block_number, nil} | ||
| # zero timestamp means the extra data is unknown or malformed | ||
| {:timestamp, 0} -> {nil, nil} | ||
| {:timestamp, timestamp} -> {nil, DateTime.from_unix!(timestamp)} |
There was a problem hiding this comment.
Using DateTime.from_unix!/1 can raise an ArgumentError if the timestamp parsed from the on-chain extra_data is extremely large (e.g., exceeding the maximum year 9999 supported by Erlang's calendar module) or otherwise malformed. To prevent potential 500 crashes on invalid external data, it is safer to use DateTime.from_unix/1 and handle the error gracefully.
{:timestamp, timestamp} ->\n case DateTime.from_unix(timestamp) do\n {:ok, datetime} -> {nil, datetime}\n {:error, _} -> {nil, nil}\n end
4ef8868 to
e7004f4
Compare
There was a problem hiding this comment.
⏱️ Adversarial Review completed (Model: qwen3.8-27b)
⚠️ Input diff exceeded 30000 chars and was truncated before review.
🔍 Verified Adversarial Review Findings
🟡 IMPORTANT
apps/block_scout_web/lib/block_scout_web/controllers/api/v2/token_controller.ex:104: Type Mismatch inTokenTotalSupplyOnDemand.trigger_fetch- Failure Trace: The diff changes the call from
TokenTotalSupplyOnDemand.trigger_fetch(ip, address_hash)toTokenTotalSupplyOnDemand.trigger_fetch(ip, token).address_hashis anExplorer.Chain.Address.Hashstruct, whiletokenis anExplorer.Chain.Tokenstruct. Unlesstrigger_fetch/2was explicitly refactored in this PR to accept aTokenstruct (which is not shown in the diff), this will cause a runtime error (e.g.,MatchErrororFunctionClauseError) when the function attempts to pattern match on the hash or access hash-specific fields. - Actionable Fix: Revert the argument to
address_hashor verify thatTokenTotalSupplyOnDemand.trigger_fetch/2has been updated to accept aTokenstruct and extract the hash internally.
- Failure Trace: The diff changes the call from
🛡️ Dismissed Claims
stats_controller.ex:105removal oftotal_gas_used: The removal of a field from a JSON response is a standard API evolution pattern (deprecation/removal). Without evidence that this is a breaking change for a specific versioned contract or that the field is required for the endpoint's core functionality, this is not a code defect but a product decision.address_controller.ex:292AddressCounters.fetchsignature: The claim is speculative ("likely relies on..."). The diff showsAddressCounters.fetch(address)being used consistently in bothaddress_controller.exandapi/v2/address_controller.exwhereaddressis a valid struct obtained fromChain.hash_to_address. Without the definition ofAddressCounters.fetch, we cannot prove a defect, and the usage is consistent with the refactoring pattern.address_controller.ex:74token transfer necessity: The claim itself concludes "This seems intentional" and identifies no concrete failure. The separation of query preloads from participant preloads is a valid optimization pattern.
9a94ec3 to
33aad08
Compare
33aad08 to
f8a1df1
Compare
Upstream Sync - v11.3.1
Auto-merge with upstream
v11.3.1failed. Version/workflow conflicts were auto-resolved,but the following files have code conflicts that need manual resolution:
To resolve:
v11.3.1to trigger Docker buildUpstream release notes