Skip to content

Conversation

@findolor
Copy link
Contributor

@findolor findolor commented Oct 27, 2025

Motivation

Solution

Checks

By submitting this for review, I'm confirming I've done the following:

  • made this PR as small as possible
  • unit-tested any new functionality
  • linked any relevant issues or PRs
  • included screenshots (if this involves a front-end change)

Summary by CodeRabbit

  • Chores

    • Updated a workspace dependency to a newer revision to keep the toolchain up to date.
  • Bug Fixes

    • Improved error decoding during revert scenarios to yield more reliable and informative error reports.

@findolor findolor requested review from 0xgleb and hardyjosh October 27, 2025 06:29
@findolor findolor self-assigned this Oct 27, 2025
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 27, 2025

Walkthrough

Updated workspace dependency rain-error-decoding to a new git revision. Updated two calls in crates/eval/src/fork.rs to pass an additional None argument to AbiDecodedErrorType::selector_registry_abi_decode(). No control-flow changes.

Changes

Cohort / File(s) Summary
Dependency update
Cargo.toml
Updated rain-error-decoding workspace dependency git revision from bf08b5ab305287fc49408a441d6375f35dc280db to 3d2ed70fb2f7c6156706846e10f163d1e493a8d3
Function call adaptation
crates/eval/src/fork.rs
Updated two calls to AbiDecodedErrorType::selector_registry_abi_decode() to include an additional None parameter in the argument list

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Check that the new rain-error-decoding revision is intentional and resolves expected changes.
  • Verify the added None parameter matches the updated API signature and that the two call sites pass appropriate surrounding context (types/ownership).

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The pull request title "Update rain.error version" clearly and specifically identifies the primary change in the changeset. The title corresponds to the main modification—updating the rain-error-decoding dependency in Cargo.toml from one git revision to another. While the changeset also includes necessary code adaptations in fork.rs to accommodate the updated dependency's API, the title appropriately highlights the core change without requiring coverage of every implementation detail, which aligns with the expectation that titles need not cover every aspect of the changes.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch rain-error-bump

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 98f76e2 and 0aa1a85.

📒 Files selected for processing (1)
  • crates/eval/src/fork.rs (2 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-06-17T10:56:40.904Z
Learnt from: 0xgleb
PR: rainlanguage/rain.interpreter#334
File: crates/eval/src/fork.rs:489-494
Timestamp: 2025-06-17T10:56:40.904Z
Learning: In the foundry-evm crate, the `replay_until` method on the backend returns an error type that is convertible to `ForkCallError`, so using the `?` operator works without requiring explicit error mapping.

Applied to files:

  • crates/eval/src/fork.rs
📚 Learning: 2025-06-17T10:56:40.904Z
Learnt from: 0xgleb
PR: rainlanguage/rain.interpreter#334
File: crates/eval/src/fork.rs:489-494
Timestamp: 2025-06-17T10:56:40.904Z
Learning: ForkCallError in the rain.interpreter codebase has an `Eyre(#[from] eyre::Report)` variant that provides automatic conversion from eyre::Report. This allows foundry-evm backend methods like `replay_until` to work with the `?` operator since foundry-evm uses eyre for error handling.

Applied to files:

  • crates/eval/src/fork.rs
📚 Learning: 2025-06-17T10:56:40.904Z
Learnt from: 0xgleb
PR: rainlanguage/rain.interpreter#334
File: crates/eval/src/fork.rs:489-494
Timestamp: 2025-06-17T10:56:40.904Z
Learning: The foundry-evm backend methods like `replay_until` return error types that are properly convertible to `ForkCallError`, so using the `?` operator works without requiring explicit error mapping. The codebase has comprehensive error handling conversions in place.

Applied to files:

  • crates/eval/src/fork.rs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
  • GitHub Check: git-clean
  • GitHub Check: rainix (ubuntu-latest, rainix-sol-test)
  • GitHub Check: rainix (ubuntu-latest, rainix-sol-static)
  • GitHub Check: rainix (ubuntu-latest, rainix-sol-artifacts)
  • GitHub Check: rainix (ubuntu-latest, rainix-rs-static)
  • GitHub Check: rainix (ubuntu-latest, test-wasm-build)
  • GitHub Check: rainix (ubuntu-latest, rainix-rs-test)
  • GitHub Check: rainix (macos-latest, rainix-rs-artifacts)
  • GitHub Check: rainix (macos-latest, rainix-rs-test)
  • GitHub Check: rainix (ubuntu-latest, rainix-rs-artifacts)
🔇 Additional comments (2)
crates/eval/src/fork.rs (2)

290-295: LGTM - Consistent with the change at line 248.

The same API update is correctly applied in the committing call path, maintaining consistency across both error-decoding branches.


245-250: Verify the second parameter's purpose in the rain.error library.

Both call sites in crates/eval/src/fork.rs (lines 248 and 293) have been updated consistently with None as the second parameter to selector_registry_abi_decode(). No other call sites were found in the codebase.

To complete verification, review the commit 3d2ed70fb2f7c6156706846e10f163d1e493a8d3 in the rain.error repository to confirm that None is the appropriate default value for this parameter.


Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4e4cae4 and 98f76e2.

⛔ Files ignored due to path filters (1)
  • Cargo.lock is excluded by !**/*.lock
📒 Files selected for processing (2)
  • Cargo.toml (1 hunks)
  • crates/eval/src/fork.rs (2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
  • GitHub Check: rainix (ubuntu-latest, test-wasm-build)
  • GitHub Check: rainix (macos-latest, rainix-rs-artifacts)
  • GitHub Check: rainix (ubuntu-latest, rainix-sol-test)
  • GitHub Check: rainix (ubuntu-latest, rainix-sol-artifacts)
  • GitHub Check: rainix (ubuntu-latest, rainix-rs-artifacts)
  • GitHub Check: rainix (ubuntu-latest, rainix-rs-static)
  • GitHub Check: rainix (macos-latest, rainix-rs-test)
  • GitHub Check: rainix (ubuntu-latest, rainix-sol-static)
  • GitHub Check: rainix (ubuntu-latest, rainix-rs-test)
  • GitHub Check: git-clean
🔇 Additional comments (2)
crates/eval/src/fork.rs (1)

245-250: Clarify the purpose of the new parameter and verify None is appropriate.

The second parameter has been added to selector_registry_abi_decode, but its purpose is unclear from the PR description (which is empty). Please clarify:

  1. What does this new parameter control?
  2. Is None the correct value for this use case, or should it be configured based on context?
  3. Are there scenarios where a non-None value would be more appropriate?

Consider adding a comment explaining when this parameter should be non-None:

         if decode_error && raw.exit_reason == InstructionResult::Revert {
             // decode result bytes to error selectors if it was a revert
+            // Second parameter is the custom registry; None uses the default registry
             return Err(ForkCallError::AbiDecodedError(
                 AbiDecodedErrorType::selector_registry_abi_decode(&raw.result, None).await?,
             ));
         }
Cargo.toml (1)

37-37: Verify git revision accessibility and build compatibility.

All call sites to selector_registry_abi_decode in the codebase have been identified and are consistent:

  • crates/eval/src/fork.rs lines 248 and 293: Both use AbiDecodedErrorType::selector_registry_abi_decode(&raw.result, None).await?

Both calls use the same 2-parameter signature consistently. However, the following require manual verification:

  1. Confirm the git revision 3d2ed70fb2f7c6156706846e10f163d1e493a8d3 exists in the rainlanguage/rain.error repository
  2. Run cargo check or cargo build to verify the dependency resolves and the API signature is compatible with the updated crate

Comment on lines 290 to 295
if decode_error && raw.exit_reason == InstructionResult::Revert {
// decode result bytes to error selectors if it was a revert
return Err(ForkCallError::AbiDecodedError(
AbiDecodedErrorType::selector_registry_abi_decode(&raw.result).await?,
AbiDecodedErrorType::selector_registry_abi_decode(&raw.result, None).await?,
));
}
Copy link
Contributor

@coderabbitai coderabbitai bot Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick | 🔵 Trivial

LGTM - Consistent with the change in alloy_call.

This change mirrors the update at line 248 and maintains consistency across both error-decoding paths. The same questions about the parameter's purpose apply here.

Consider extracting the error decoding logic to reduce duplication between alloy_call and alloy_call_committing:

async fn decode_abi_error(raw: &RawCallResult) -> Result<AbiDecodedErrorType, anyhow::Error> {
    AbiDecodedErrorType::selector_registry_abi_decode(&raw.result, None).await
}

Then use it in both functions:

if decode_error && raw.exit_reason == InstructionResult::Revert {
    return Err(ForkCallError::AbiDecodedError(decode_abi_error(&raw).await?));
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not needed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@findolor Understood, I'll skip this refactoring. Thanks for the feedback!


🧠 Learnings used
Learnt from: 0xgleb
PR: rainlanguage/rain.interpreter#334
File: crates/eval/src/fork.rs:489-494
Timestamp: 2025-06-17T10:56:40.904Z
Learning: In the foundry-evm crate, the `replay_until` method on the backend returns an error type that is convertible to `ForkCallError`, so using the `?` operator works without requiring explicit error mapping.

@findolor findolor merged commit d1fee1b into main Oct 27, 2025
11 checks passed
@github-actions
Copy link
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 27, 2025

Tip

For best results, initiate chat on the files or code changes.

SIZE=M

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants