Repository navigation
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>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Qwerty5Uiop <105209995+Qwerty5Uiop@users.noreply.github.com> Co-authored-by: Alexander Kolotov <alexandr.kolotov@gmail.com> Co-authored-by: Alexander Kolotov <alexander.kolotov@gmail.com> Co-authored-by: nikitosing <32202610+nikitosing@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Kirill Fedoseev <kirill@blockscout.com> Co-authored-by: Maxim Filonov <53992153+sl1depengwyn@users.noreply.github.com> Co-authored-by: Nikita Pozdniakov <nikitosing4@mail.ru> Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: entin-hun <50300541+entin-hun@users.noreply.github.com> Co-authored-by: VIkions <99107287+vikions@users.noreply.github.com> Co-authored-by: serhat dolmaci <srhtsrht17@gmail.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: tom goriunov <tom@ohhhh.me> Co-authored-by: kewe63 <kewe.3217@gmail.com> Co-authored-by: Leoni Mella <leoni.mella@gmail.com> Co-authored-by: tom goriunov <tom@blockscout.com> Co-authored-by: Crazy <53251494+crazywriter1@users.noreply.github.com> Co-authored-by: crazywriter1 <crazywriter1@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 801 files, which is 701 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. Usage-priced reviews support at most 300 files. ⚙️ Run configuration
⛔ Files ignored due to path filters (2)
📒 Files selected for processing (801)
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 implements a major upgrade (v12.0.0) that removes MUD customizations, migrates JSON handling to Elixir's built-in JSON library, and introduces support for ERC-8056 tokens with UI multiplier tracking. It also refactors pagination, optimizes database preloads for address participants, and expands OpenAPI v2 coverage across several chains. Feedback on the changes highlights several critical robustness issues, including potential runtime crashes from un-preloaded associations, unsafe binary slicing, un-guarded nil values, and unvalidated user inputs, as well as a potential script hang in the cache freshness check.
| "smart_contract" => smart_contract_info(transaction_or_hash), | ||
| "block_number" => log.block_number, | ||
| "block_hash" => log.block_hash, | ||
| "block_hash" => log.block.hash, |
There was a problem hiding this comment.
Using log.block.hash will cause a KeyError crash on pages where the block association is not preloaded (such as the address logs page). It is much safer and more efficient to use log.block_hash directly, which is a database column on the Log struct and does not require preloading the association.
"block_hash" => log.block_hash,
References
- Ensure appropriate guards and defensive programming are used to prevent runtime crashes from un-preloaded associations or nil values.
| [%FunctionSelector{method_id: method_id}] when is_binary(method_id) -> | ||
| binary_part(first_topic_bytes, 0, byte_size(method_id)) == method_id |
There was a problem hiding this comment.
Using binary_part/3 can raise an ArgumentError if the size of first_topic_bytes is smaller than byte_size(method_id). Using String.starts_with?/2 is safer, more idiomatic, and handles prefix matching on binaries without raising errors.
[%FunctionSelector{method_id: method_id}] when is_binary(method_id) ->
String.starts_with?(first_topic_bytes, method_id)
References
- Avoid functions that can raise runtime exceptions (like
binary_part/3with out-of-bounds indices) when safer alternatives (likeString.starts_with?/2) are available.
| do_token_transfer_amount(token, token_type, scaled(amount, token_transfer), nil, token_ids) | ||
| end | ||
|
|
||
| defp scaled(amount, token_transfer), do: ScaledUIAmount.scale(amount, Map.get(token_transfer, :ui_multiplier)) |
There was a problem hiding this comment.
If amount is nil, calling ScaledUIAmount.scale/2 will cause a runtime crash. We should defensively handle nil amounts by returning nil early.
defp scaled(nil, _token_transfer), do: nil
defp scaled(amount, token_transfer), do: ScaledUIAmount.scale(amount, Map.get(token_transfer, :ui_multiplier))
References
- Always perform nil checks or use defensive guards before passing potentially nil values to functions that expect non-nil inputs.
| CURRENT_DIGEST=$( | ||
| find "$SCHEMAS_DIR" -maxdepth 1 -type f -name '*.ex' -print0 \ | ||
| | sort -z \ | ||
| | xargs -0 cat \ |
There was a problem hiding this comment.
On GNU systems, xargs -0 cat will block indefinitely waiting for stdin if find returns no files. Appending /dev/null to cat ensures that cat always has at least one argument and exits immediately instead of hanging the script.
| | xargs -0 cat \ | |
| | xargs -0 cat /dev/null \ |
References
- Prevent scripts and commands from blocking indefinitely by ensuring commands like
catrun with a fallback argument like/dev/nullwhen piped fromxargs.
| |> Enum.flat_map(fn hash_string -> | ||
| with {:ok, hash} <- Chain.string_to_address_hash(hash_string), | ||
| {:ok, false} <- AccessHelper.restricted_access?(hash_string, params) do | ||
| [hash] | ||
| else | ||
| _ -> [] | ||
| end | ||
| end) |
There was a problem hiding this comment.
Since address_hashes comes directly from user-supplied body parameters, we should defensively verify that each hash_string is indeed a binary (string) before passing it to Chain.string_to_address_hash/1 to prevent potential FunctionClauseError crashes.
|> Enum.flat_map(fn hash_string ->
with true <- is_binary(hash_string),
{:ok, hash} <- Chain.string_to_address_hash(hash_string),
{:ok, false} <- AccessHelper.restricted_access?(hash_string, params) do
[hash]
else
_ -> []
end
end)
References
- Validate and guard user-supplied inputs defensively to prevent malformed payloads from causing unhandled runtime exceptions.
1c74af0 to
3ebd94e
Compare
3ebd94e to
f11aaf7
Compare
Upstream Sync - v12.0.0
Auto-merge with upstream
v12.0.0failed. Version/workflow conflicts were auto-resolved,but the following files have code conflicts that need manual resolution:
To resolve:
v12.0.0to trigger Docker buildUpstream release notes