test(katana): feeder gateway tests #3038
Conversation
kariy
force-pushed
the
katana/feeder-gateway-test
branch
from
e49763a to
b40528d
Compare
|
Ohayo, sensei! Below is the detailed breakdown of the changes: WalkthroughThis pull request introduces several refactorings and minor feature enhancements across multiple modules. The updates include type conversion adjustments in the executor, additional development dependencies, and deriving equality traits for various types in the feeder gateway. New JSON fixtures and test functions have been added to support blockchain state updates and block retrievals, while modifications in primitive and RPC modules streamline built-in counter handling through method calls instead of function lookups. Changes
Sequence Diagram(s)sequenceDiagram
participant Test as Test Function
participant Gateway as SequencerGateway
participant Fixture as JSON Fixture Loader
Test->>Gateway: call get_block(block_number)
Gateway->>Fixture: load fixture data for block
Fixture-->>Gateway: return JSON Block Data
Gateway-->>Test: return Block Data
sequenceDiagram
participant Client as RPC Client
participant RPC as RPC Endpoint
participant Resources as ExecutionResources
Client->>RPC: Request trace resource data
RPC->>Resources: Call builtin_instance_counter.method()
Resources-->>RPC: Return built-in counter values
RPC-->>Client: Return execution resources data
Possibly related PRs
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
crates/katana/feeder-gateway/tests/fixtures/0.13.4/state_update/sepolia_integration_63881.json (1)
83-83:⚠️ Potential issueOhayo sensei, Extraneous Content Detected!
The line containing just83appears to be stray content that could potentially invalidate the JSON. Please remove this line so that the fixture remains a valid JSON file.
🧹 Nitpick comments (9)
crates/katana/feeder-gateway/tests/fixtures/mod.rs (2)
11-15: Enhance error handling in test data loading.Ohayo! The error handling could be more descriptive for test debugging sensei.
Consider this improvement:
pub fn test_data<T: DeserializeOwned>(path: &str) -> T { let dir = PathBuf::from("tests/fixtures"); - let file = File::open(dir.join(path)).expect("failed to open file"); - serde_json::from_reader(BufReader::new(file)).expect("failed to read file") + let file_path = dir.join(path); + let file = File::open(&file_path) + .unwrap_or_else(|e| panic!("Failed to open file {}: {}", file_path.display(), e)); + serde_json::from_reader(BufReader::new(file)) + .unwrap_or_else(|e| panic!("Failed to parse JSON from {}: {}", file_path.display(), e)) }
17-20: Add documentation for the gateway fixture.Ohayo sensei! The fixture would benefit from documentation explaining its purpose and usage.
Consider adding documentation:
+/// Returns a SequencerGateway instance configured for mainnet testing. +/// +/// This fixture is used with rstest to provide a consistent gateway instance +/// across test cases. #[rstest::fixture] pub fn gateway() -> SequencerGateway { SequencerGateway::sn_mainnet() }crates/katana/feeder-gateway/tests/mainnet.rs (1)
39-47: Enhance error handling in state update test.Ohayo sensei! While the test is well-structured, we could improve error handling for better debugging.
Consider this improvement:
async fn get_state_update( gateway: SequencerGateway, #[case] block_number: BlockNumber, #[case] expected: StateUpdate, ) { let id = BlockIdOrTag::Number(block_number); - let state_update = gateway.get_state_update(id).await.unwrap(); + let state_update = gateway.get_state_update(id).await + .unwrap_or_else(|e| panic!("Failed to get state update for block {}: {}", block_number, e)); similar_asserts::assert_eq!(state_update, expected); }crates/katana/feeder-gateway/src/types/receipt.rs (2)
28-32: Consider deriving more traits, sensei.The
ExecutionResourcesstruct could benefit from derivingDeserializefor consistency with other types.-#[derive(Debug, PartialEq, Eq)] +#[derive(Debug, PartialEq, Eq, Deserialize)]
50-175: Excellent deserialization implementation, sensei!The manual deserialization implementation is well-documented and handles complex JSON formats efficiently. The use of helper types and visitors shows great attention to detail.
However, consider adding error tests to verify deserialization behavior with invalid inputs.
crates/katana/feeder-gateway/tests/fixtures/0.13.0/state_update/mainnet_550000.json (3)
21-35: Nonces Mapping Integrity
Ohayo, sensei! Thenoncesobject is organized with keys as addresses and values in hexadecimal format, which is ideal. In future iterations, consider adding unit tests to validate that your parsing logic correctly interprets these values and that they conform to expected numeric ranges.
37-213: Replaced Classes Consistency
Ohayo, sensei! Thereplaced_classesarray includes several entries, each with anaddressand a correspondingclass_hash. The structure is consistent throughout. It might be helpful to add brief documentation or comments (externally or within tests) noting the intended semantics for these replacements so that future contributors can quickly grasp their importance.
215-1805: Comprehensive Storage Diffs Coverage
Ohayo, sensei! Thestorage_diffssection is impressively detailed, covering a wide range of contract addresses and their associated storage changes. While this comprehensive fixture is excellent for full integration tests, you may want to evaluate whether every detail is needed for each test. Splitting or simplifying the fixture in certain scenarios could speed up test execution and make maintenance easier.crates/katana/feeder-gateway/tests/fixtures/0.10.0/state_update/mainnet_6500.json (1)
5-2140: Ohayo, Sensei! Comprehensive State Diff Fixture DetectedThis JSON fixture is impressively detailed, capturing a full state update with fields like
declared_classes,deployed_contracts, and especially the extensivestorage_diffs. The nested structure is syntactically valid and the use of hex strings (prefixed with"0x") is consistent with our blockchain data format. Given the complexity and size of this file, I recommend considering the following:
- Schema Validation: It might be beneficial to incorporate a JSON schema in our test suite to validate the structure of such detailed fixtures automatically.
- Modularity and Maintenance: If parts of this fixture (for example, common contract storage diff patterns) are reused elsewhere, think about modularizing them or maintaining them in separate files for ease of updates.
Overall, this fixture is solid—just a little extra validation may save headaches in the future.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (28)
crates/katana/executor/src/implementation/blockifier/utils.rs(1 hunks)crates/katana/feeder-gateway/Cargo.toml(1 hunks)crates/katana/feeder-gateway/src/types/mod.rs(3 hunks)crates/katana/feeder-gateway/src/types/receipt.rs(1 hunks)crates/katana/feeder-gateway/src/types/transaction.rs(6 hunks)crates/katana/feeder-gateway/tests/fixtures/0.10.0/state_update/mainnet_6500.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.12.2/state_update/mainnet_350000.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.13.0/state_update/mainnet_550000.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.13.1/state_update_with_block/sepolia_integration_9703.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.13.1/state_update_with_block/sepolia_integration_pending.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.13.2/block/sepolia_integration_35748.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.13.2/state_update/sepolia_integration_35748.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.13.4/block/sepolia_integration_63881.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.13.4/state_update/sepolia_integration_63881.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/0.7.0/state_update/mainnet_2240.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/README.md(1 hunks)crates/katana/feeder-gateway/tests/fixtures/mod.rs(1 hunks)crates/katana/feeder-gateway/tests/fixtures/pre_0.7.0/block/mainnet_genesis.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/pre_0.7.0/state_update/mainnet_genesis.json(1 hunks)crates/katana/feeder-gateway/tests/fixtures/pre_0.7.0/state_update_with_block/mainnet_genesis.json(1 hunks)crates/katana/feeder-gateway/tests/mainnet.rs(1 hunks)crates/katana/primitives/src/trace.rs(5 hunks)crates/katana/rpc/rpc-types/src/class.rs(1 hunks)crates/katana/rpc/rpc-types/src/lib.rs(0 hunks)crates/katana/rpc/rpc-types/src/receipt.rs(1 hunks)crates/katana/rpc/rpc-types/src/trace.rs(1 hunks)crates/katana/rpc/rpc-types/src/utils.rs(0 hunks)crates/katana/rpc/rpc/src/starknet/trace.rs(2 hunks)
💤 Files with no reviewable changes (2)
- crates/katana/rpc/rpc-types/src/lib.rs
- crates/katana/rpc/rpc-types/src/utils.rs
✅ Files skipped from review due to trivial changes (4)
- crates/katana/feeder-gateway/tests/fixtures/README.md
- crates/katana/feeder-gateway/tests/fixtures/0.13.2/block/sepolia_integration_35748.json
- crates/katana/feeder-gateway/tests/fixtures/0.12.2/state_update/mainnet_350000.json
- crates/katana/feeder-gateway/tests/fixtures/0.13.4/block/sepolia_integration_63881.json
👮 Files not reviewed due to content moderation or server errors (2)
- crates/katana/feeder-gateway/tests/fixtures/0.13.1/state_update_with_block/sepolia_integration_pending.json
- crates/katana/feeder-gateway/tests/fixtures/0.13.1/state_update_with_block/sepolia_integration_9703.json
🧰 Additional context used
🪛 Gitleaks (8.21.2)
crates/katana/feeder-gateway/tests/fixtures/pre_0.7.0/state_update_with_block/mainnet_genesis.json
687-687: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
691-691: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
695-695: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
699-699: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
705-705: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
709-709: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
719-719: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
723-723: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
727-727: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
731-731: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
737-737: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
741-741: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
745-745: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
749-749: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
753-753: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
757-757: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
767-767: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: docs
- GitHub Check: clippy
- GitHub Check: build
- GitHub Check: ensure-wasm
🔇 Additional comments (44)
crates/katana/feeder-gateway/tests/fixtures/0.13.2/state_update/sepolia_integration_35748.json (8)
1-4: Ohayo, sensei: Top-Level JSON Structure Verification
The top-level keys"block_hash","new_root", and"old_root"are clearly defined and adhere nicely to the expected state update schema.
5-12: Ohayo, sensei: Storage Diffs Structure Check
The"state_diff"object properly nests"storage_diffs", and the entry for key"0x1"correctly uses an array of objects containing"key"and"value". This aligns well with the intended schema.
13-22: Ohayo, sensei: Multiple Storage Diff Entries Validated
The storage diff for address"0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7"includes two update objects, which is correctly structured. Please double-check that these values correspond to valid state transitions as per the blockchain state update design.
24-26: Ohayo, sensei: Nonces Data Mapped Correctly
The"nonces"mapping is using string representations (e.g.,"0xf") for nonce values, which is a common practice in blockchain JSON payloads.
27-28: Ohayo, sensei: Contracts Arrays Initialization
Both"deployed_contracts"and"old_declared_contracts"are correctly represented as empty arrays, indicating no contracts were deployed or removed in this update.
29-38: Ohayo, sensei: Declared Classes Enumeration Checked
The"declared_classes"array includes objects with"class_hash"and"compiled_class_hash", which fits neatly into the overall state update data model. Just ensure these hashes are consistent with other components of the system.
39-40: Ohayo, sensei: Replaced Classes Field Validated
The"replaced_classes"field is an empty array, effectively indicating that no classes have been replaced in this update, as expected.
41-42: Ohayo, sensei: File Closure and Formatting
The file properly terminates with the closing curly brace. However, please verify that the final line (showing “42”) is intentional and not an extraneous artifact.crates/katana/feeder-gateway/tests/mainnet.rs (2)
10-27: Well-structured test implementation!Ohayo sensei! The test cases are comprehensive and well-organized, covering multiple versions from pre-0.7.0 to 0.13.0.
59-67: Consistent test implementation!Ohayo sensei! The test follows the same well-structured pattern as the others, maintaining consistency across the test suite.
crates/katana/rpc/rpc-types/src/trace.rs (1)
50-58: Clean refactoring of builtin counter access!Ohayo sensei! The changes to use direct method calls instead of function calls improve code readability and maintainability.
crates/katana/feeder-gateway/src/types/mod.rs (1)
26-27: Well-structured trait derivations!Ohayo sensei! The addition of
PartialEqandEqtraits to these types enables proper equality comparisons in tests. The changes are consistent across all related types.Also applies to: 34-35, 42-43, 52-53, 58-59, 64-65, 71-72, 81-82
crates/katana/feeder-gateway/src/types/receipt.rs (1)
21-26: Ohayo! Nice enum design for execution status.The
ExecutionStatusenum withSCREAMING_SNAKE_CASEserialization is well-structured and clear.crates/katana/rpc/rpc-types/src/receipt.rs (1)
171-187: Ohayo! Clean refactoring of builtin counter access.The direct method calls on
builtin_instance_counterimprove code readability and maintainability.crates/katana/primitives/src/trace.rs (3)
133-197: Excellent API design for builtin counters, sensei!The comprehensive set of methods for accessing different builtin types is well-documented and type-safe.
199-211: Nice generic implementation, sensei!The generic
Fromimplementation withInto<usize>constraint is flexible and reusable.
213-229: Good iterator support!The implementation of both consuming and reference iterators provides flexible access patterns.
crates/katana/rpc/rpc/src/starknet/trace.rs (1)
273-295: Ohayo! Clean conversion to RPC resources.The direct use of builtin counter methods simplifies the code and improves readability.
crates/katana/rpc/rpc-types/src/class.rs (1)
74-74: Ohayo! Adding equality traits looks good!Adding
PartialEqandEqtraits toRpcSierraContractClassenables proper equality comparisons, which is particularly useful for testing scenarios.crates/katana/feeder-gateway/src/types/transaction.rs (1)
15-15: Ohayo! Consistent trait derivation across transaction types!Adding
PartialEqandEqtraits to all transaction-related types enables consistent equality comparisons throughout the codebase. This is especially valuable for testing and validation scenarios.Also applies to: 23-23, 37-37, 61-61, 69-69, 76-76, 90-90, 121-121, 147-147
crates/katana/executor/src/implementation/blockifier/utils.rs (1)
684-684:✅ Verification successful
Ohayo! Let's verify this type conversion sensei!
The change from direct assignment to using
.into()forbuiltin_instance_countersuggests a type conversion between HashMap types. Let's verify this conversion is safe.
🏁 Script executed:
#!/bin/bash # Search for the definition and usage of BuiltinCounters to verify the conversion rg -A 5 "struct BuiltinCounters"Length of output: 500
Ohayo sensei! The type conversion here is solid.
- The definition of
BuiltinCountersincrates/katana/primitives/src/trace.rsshows it as a tuple struct wrapping aHashMap<BuiltinName, usize>.- The usage of
.into()onresources.builtin_instance_countersafely converts a compatibleHashMapinto aBuiltinCountersinstance (leveraging an appropriateFrom/Intoimplementation).No further changes are needed.
crates/katana/feeder-gateway/Cargo.toml (1)
20-22: Ohayo! Great choice of testing dependencies sensei!Adding these dev-dependencies enhances the testing capabilities:
rstest: For parameterized testingserde_json: For JSON serialization in testssimilar-asserts: For more readable assertion failuresUsing workspace-level version management ensures consistency across the project.
crates/katana/feeder-gateway/tests/fixtures/pre_0.7.0/state_update/mainnet_genesis.json (1)
1-125: Ohayo, Sensei – Genesis State Update Fixture Looks Solid!
This new JSON file capturing the mainnet genesis state update is very well structured. All the key fields (like"block_hash","new_root","old_root", and the detailed"state_diff") are present and clearly organized. The arrays for deployed contracts and the storage diffs are comprehensive for testing equality and state verification.crates/katana/feeder-gateway/tests/fixtures/pre_0.7.0/block/mainnet_genesis.json (1)
1-256: Ohayo, Sensei – Mainnet Genesis Block Fixture is On Point!
This JSON file representing the genesis block is succinct and complete. It includes essential fields like"block_number","parent_block_hash", as well as arrays for transactions and receipts that are necessary for simulating the initial state of the blockchain. The clarity in delineating deploy and invoke-function types makes it very useful for integration tests.crates/katana/feeder-gateway/tests/fixtures/pre_0.7.0/state_update_with_block/mainnet_genesis.json (1)
1-774: Ohayo, Sensei – Mainnet Genesis State Update Fixture is Rock Solid!
This file is impressively comprehensive, capturing both detailed block data and an extensive"state_update"object with all nested diffs. Every critical field—from"block_hash","new_root", and"old_root"to the intricate"state_diff"(including deployed contracts, nonces, and storage diffs)—is well laid out.A couple of notes:
• The hexadecimal strings you see (e.g., contract addresses and class hashes) may trigger static analysis tools with generic API key warnings (as noted around lines 687–767). However, rest assured these are simply blockchain identifiers used in our testing fixtures rather than actual secret keys.
• It might be useful to document in a comment within the file (or in our test documentation) that these values are intentionally hardcoded identifiers for testing purposes, to avoid any confusion.Overall, the file adheres to our test data structure and integrates perfectly with our updated modules.
🧰 Tools
🪛 Gitleaks (8.21.2)
687-687: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
691-691: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
695-695: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
699-699: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
705-705: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
709-709: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
719-719: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
723-723: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
727-727: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
731-731: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
737-737: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
741-741: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
745-745: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
749-749: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
753-753: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
757-757: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
767-767: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
crates/katana/feeder-gateway/tests/fixtures/0.13.0/state_update/mainnet_550000.json (4)
1-5: Block Metadata Validation
Ohayo, sensei! The top-level metadata fields—block_hash,new_root, andold_root—are clearly presented as hexadecimal strings, which is great. Please ensure these values remain consistent with on-chain formats in your tests.
6-20: Deployed Contracts and Declared Classes Structure
Ohayo, sensei! Thedeclared_classesfield is correctly set to an empty array, and thedeployed_contractsarray features objects with bothaddressandclass_hashproperties. The consistent structure makes the fixture easy to consume. It’s a good idea to double-check that all of these hex strings are valid and up-to-date with your blockchain specifications.
36-36: Old Declared Contracts Field
Ohayo, sensei! Theold_declared_contractsfield is intentionally an empty array, and this is perfectly acceptable if no previous contracts are being removed.
1806-1806: JSON Structure Termination
Ohayo, sensei! The file ends correctly with the closing brace on line 1806, ensuring the JSON structure is properly terminated.crates/katana/feeder-gateway/tests/fixtures/0.10.0/state_update/mainnet_6500.json (1)
1-4: Ohayo, Sensei! Key Header Properties Look AwesomeThe top-level properties—
block_hash,new_root, andold_root—are all present and use the expected hexadecimal notation. This matches our blockchain conventions nicely, so no issues here.crates/katana/feeder-gateway/tests/fixtures/0.7.0/state_update/mainnet_2240.json (6)
1-4: Ohayo, sensei – Block Information Looks Neat!
The fieldsblock_hash,new_root, andold_rootare formatted properly with valid hexadecimal strings. Everything here appears spot on.
5-6: Ohayo, sensei – State Diff Metadata is Clear!
Thedeclared_classesis an empty array as expected when no classes are declared. This clear structure sets the stage for the subsequent state changes.
7-536: Ohayo, sensei – Deployed Contracts Section is Well Populated!
Thedeployed_contractsarray contains numerous entries with consistentaddressandclass_hashfields. Notably, almost all entries share the sameclass_hashexcept for one (around lines 241–243) that uses a distinct value. Please verify that this discrepancy is intentional and accurately reflects your blockchain state update.
537-539: Ohayo, sensei – Additional State Diff Fields Check Out!
Thenonces,old_declared_contracts, andreplaced_classesare all empty objects/arrays, which is perfectly acceptable when there are no changes to report in these categories.
540-2088: Ohayo, sensei – Storage Diffs Are Impressively Detailed!
This section is highly detailed, listing numerous contract addresses with their corresponding storage key–value pairs. It’s crucial to verify that all these entries are accurate and that no sensitive data is inadvertently exposed. If this fixture is intended for testing purposes, the level of detail is great; however, consider adding documentation on how these values are generated to aid future maintenance.
2089-2091: Ohayo, sensei – JSON File Closure is Spot On!
The JSON object is properly terminated, ensuring that the file maintains valid syntax.crates/katana/feeder-gateway/tests/fixtures/0.13.4/state_update/sepolia_integration_63881.json (8)
1-4: Ohayo sensei, Header Fields Look Solid!
The top-level keys (block_hash,new_root, andold_root) are properly defined with consistent hex-formatted strings. This clear structure will be very helpful for downstream tests.
5-12: Ohayo sensei, Well-Structured State Diff!
Thestate_diffobject and its nestedstorage_diffsfor the account"0x1"are cleanly set up with clear key-value pairs. The format is consistent and should integrate well with your tests.
13-22: Ohayo sensei, Consistent Storage Update for Address 0x4718f5a0...
The storage diff entry for account"0x4718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d"is clear with its two update objects. Ensure that the order or duplication of keys (if any) is intentional when processing these diffs.
23-56: Ohayo sensei, Comprehensive Updates for Account 0x2!
The several update objects provided for account"0x2"appear thorough. Please verify that the ordering of these diff entries is as intended in case it affects state reconciliation. The consistent use of hex values for keys and values is spot on.
57-62: Ohayo sensei, Clear Single Update for Account 0x779094b2b6a74ddf...
The storage diff for account"0x779094b2b6a74ddf686f81573c7fb8be4f93f3d7ce3aed8ef8f70aaceefc213"is succinct with one update object, and the structure aligns with the rest of the file.
63-72: Ohayo sensei, Storage Diffs for Account 0x49d36570d4e46f48e99674bd3... Are Consistent!
The two update objects under key"0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7"maintain consistency with prior entries. Just ensure that the specific keys used are exactly what your processing engine expects.
73-80: Ohayo sensei, Ancillary State Details Look Fine!
The additional properties such as"nonces","deployed_contracts","old_declared_contracts","declared_classes", and"replaced_classes"are clearly defined. Even though many arrays are empty, this is acceptable for a fixture setup—just update them as needed for future tests.
81-82: Ohayo sensei, JSON Closure is Neat!
The JSON object is properly closed, ensuring that the main data structure is intact and valid (assuming only the main object should be present).
| #[rstest::fixture] | ||
| pub fn gateway_sepolia() -> SequencerGateway { | ||
| SequencerGateway::sn_mainnet() | ||
| } |
There was a problem hiding this comment.
Fix inconsistency in gateway_sepolia fixture.
Ohayo sensei! There's a critical inconsistency - the fixture is named gateway_sepolia but uses mainnet configuration.
Apply this fix:
#[rstest::fixture]
pub fn gateway_sepolia() -> SequencerGateway {
- SequencerGateway::sn_mainnet()
+ SequencerGateway::sn_sepolia()
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #[rstest::fixture] | |
| pub fn gateway_sepolia() -> SequencerGateway { | |
| SequencerGateway::sn_mainnet() | |
| } | |
| #[rstest::fixture] | |
| pub fn gateway_sepolia() -> SequencerGateway { | |
| SequencerGateway::sn_sepolia() | |
| } |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3038 +/- ##
=======================================
Coverage 56.20% 56.20%
=======================================
Files 437 437
Lines 58769 58821 +52
=======================================
+ Hits 33029 33060 +31
- Misses 25740 25761 +21 ☔ View full report in Codecov by Sentry. |
Summary by CodeRabbit
New Features
Refactor
Tests
Documentation