Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(katana): update execution error message #2322

Merged
merged 1 commit into from
Aug 21, 2024
Merged

refactor(katana): update execution error message #2322

merged 1 commit into from
Aug 21, 2024

Conversation

kariy
Copy link
Member

@kariy kariy commented Aug 21, 2024

Initially, i defined custom execution error messages for two main reasons:-

  1. Removing any Debugs formatting in the error messages returned by executor (ie blockifier)
  2. To standardize the messages across different executor implementations (when we were supporting both starknet-in-rust 🪦 and blockifier)

But reason no.1 is more intrusive as the errors are returned to user-space. Blockifier used to use Debug formatting in their error messages (they have since slowly removing the Debugs but there are still some left). For example ref:

#[error("Class with hash {class_hash:?} is already declared.")]
DeclareTransactionError { class_hash: ClassHash }

and IMO this would output the error message string with debug info which results in not so appealing/readable message. This message is also used as a response data in the JSON-RPC server through the Starknet API. The Katana messages are more or less similar to its original counterpart but with slight variations in the wordings.

So the main idea of the redundancy was to provide user with more human readable and 'easier' to understand messages, but due to the string itself being different, if you wanna extract the individual atomic values (eg nonce, fee) from the string, you have to do it differently for katana vs other nodes (or gateway).

Important thing to note, however, the error message is not strictly defined in the JSON-RPC specs so Katana returning different error messages than blockifier is not technically wrong.

but @tarrencev needed them to be similar with the ones returned by Pathfinder, for some of Cartridge's internal operations. At least for these two errors:

  1. Invalid transaction nonce:

Katana:

invalid transaction nonce: expected 2 got 1

Pathfinder:

Invalid transaction nonce of contract at address 0x07ee88d7b4da7b83bf2eeb0c530a126e3b586d5da2b44e39c4fa54e74a0d4cce. Account nonce: 0x0000000000000000000000000000000000000000000000000000000000000194; got: 0x000000000000000000000000000000000000000000000000000000000000012f.
  1. Insufficient balance:

This is from older version of Katana, latest version outputs the same one as Pathfinder.

Katana:

Max fee (Fee(24129000)) exceeds balance (Uint256(StarkFelt(\"0x0000000000000000000000000000000000000000000000000000000000000000\"), StarkFelt(\"0x0000000000000000000000000000000000000000000000000000000000000000\"

Pathfinder:

Max fee (193191155591958) exceeds balance (124008699329154).

Eventually, we'd probably remove this redundant error enum and use directly from blockifier. But for now, we just copy the exact string.

Summary by CodeRabbit

  • New Features

    • Enhanced error messages for improved clarity and consistency across various error types.
    • Detailed multi-line error message for the InvalidNonce error, including specific fields for better debugging.
  • Bug Fixes

    • Improved handling of the InvalidNonce variant in the transaction pre-validation error conversion, adding context for better error reporting.

Copy link

coderabbitai bot commented Aug 21, 2024

Walkthrough

Ohayo, sensei! The recent changes primarily focus on enhancing the error handling in the ExecutionError enum. Error messages have been standardized for clarity, with consistent capitalization, and the InvalidNonce error has been restructured to provide more detailed context. Additionally, modifications in the conversion of TransactionPreValidationError to ExecutionError improve the richness of error reporting, making debugging easier and enhancing overall user experience.

Changes

Files Change Summary
crates/katana/executor/src/abstraction/error.rs
crates/katana/executor/src/implementation/blockifier/error.rs
Error messages in ExecutionError were standardized for consistency. The InvalidNonce error was restructured to provide detailed fields, enhancing clarity. The implementation converting TransactionPreValidationError to ExecutionError was updated to include these new fields for improved error context.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant System
    participant ErrorHandler
    
    User->>System: Initiates transaction
    System->>ErrorHandler: Validates transaction
    alt Invalid Nonce Detected
        ErrorHandler->>User: Returns InvalidNonce error
        ErrorHandler->>System: Logs detailed error info (address, current_nonce, tx_nonce)
    end
Loading

Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between bb7d7df and b649df7.

Files selected for processing (2)
  • crates/katana/executor/src/abstraction/error.rs (1 hunks)
  • crates/katana/executor/src/implementation/blockifier/error.rs (1 hunks)
Additional comments not posted (11)
crates/katana/executor/src/abstraction/error.rs (10)

12-12: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


15-15: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


18-18: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


21-21: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


24-24: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


27-27: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


46-49: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


51-51: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


54-54: Ohayo, sensei! Capitalization improves readability.

The capitalization of the error message enhances consistency and clarity.


32-43: Ohayo, sensei! Restructured InvalidNonce improves context.

The restructuring of the InvalidNonce error message provides more detailed information, enhancing debugging and user experience.

Run the following script to verify the usage of the new InvalidNonce structure:

Verification successful

Ohayo, sensei! Let's fix that little hiccup and try again to verify the usage of our newly structured InvalidNonce. Here's a fresh script to get us back on track:


Ohayo, sensei! The InvalidNonce structure is well-integrated.

The new InvalidNonce structure is being utilized correctly in the codebase, enhancing the error handling with detailed context.

  • File: crates/katana/executor/src/implementation/blockifier/error.rs

Everything looks good! 🌟

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the new `InvalidNonce` structure.

# Test: Search for the `InvalidNonce` usage. Expect: Only occurrences of the new structure.
rg --type rust -A 5 $'InvalidNonce {'

Length of output: 130


Script:

#!/bin/bash
# Description: Verify the usage of the new `InvalidNonce` structure.

# Test: Search for the `InvalidNonce` usage. Expect: Only occurrences of the new structure.
rg --type rust -A 5 $'InvalidNonce \\{'

Length of output: 1606

crates/katana/executor/src/implementation/blockifier/error.rs (1)

66-73: Ohayo, sensei! Enhanced InvalidNonce conversion improves context.

The inclusion of the address field and renaming actual to tx_nonce provides better clarity and context for the error.

Run the following script to verify the usage of the new InvalidNonce conversion structure:

Verification successful

Ohayo, sensei! Let's fix that little hiccup and dive deeper to verify the InvalidNonce conversion structure. I'll correct the script and run it again to ensure we get the right insights.


Ohayo, sensei! The InvalidNonce conversion structure is spot on.

The improved conversion structure, including the address field and renaming actual to tx_nonce, is correctly implemented across the codebase. This enhances the clarity and context of the error messages.

  • Verified in crates/katana/executor/src/abstraction/error.rs
  • Verified in crates/katana/executor/src/implementation/blockifier/error.rs
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the new `InvalidNonce` conversion structure.

# Test: Search for the `InvalidNonce` conversion. Expect: Only occurrences of the new structure.
rg --type rust -A 5 $'InvalidNonce {'

Length of output: 130


Script:

#!/bin/bash
# Corrected script to verify the usage of the new `InvalidNonce` conversion structure.

# Test: Search for the `InvalidNonce` conversion. Expect: Only occurrences of the new structure.
rg --type rust -A 5 'InvalidNonce \{'

Length of output: 1606


Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

codecov bot commented Aug 21, 2024

Codecov Report

Attention: Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.

Project coverage is 67.31%. Comparing base (bb7d7df) to head (b649df7).
Report is 1 commits behind head on main.

Files Patch % Lines
...na/executor/src/implementation/blockifier/error.rs 0.00% 6 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2322      +/-   ##
==========================================
- Coverage   67.31%   67.31%   -0.01%     
==========================================
  Files         354      354              
  Lines       46433    46437       +4     
==========================================
  Hits        31258    31258              
- Misses      15175    15179       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@glihm glihm left a comment

Choose a reason for hiding this comment

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

Sounds good, thanks for the detailed reasons and update. 👍

@kariy
Copy link
Member Author

kariy commented Aug 21, 2024

thanks for the detailed reasons and update. 👍

image

@kariy kariy merged commit 8db91e7 into main Aug 21, 2024
14 of 15 checks passed
@kariy kariy deleted the katana/errors branch August 21, 2024 17:22
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.

2 participants