fix(core): fix upgrade with enum keys

[remybar]

Description

In the way we check if a model can be upgraded, some cases for key members are not well managed.

Here are the key member upgrade rules that are checked according to the key member type:

• Primitive: same than for a value member, the new type must have the same or a bigger size than the old type (u8 -> u16),
• Struct: new members are NOT allowed. Existing member types must follow the key member upgrade rules,
• Enum: new variants are allowed. Existing variant data types must follow the key member upgrade rules,
• Tuple: tuple items must follow the key member upgrade rules and the tuple size must remain the same,
• Array: the array item type must follow the key member upgrade rules,
• ByteArray: always allowed.

Tests

• Yes
• No, because they aren't needed
• [] No, because I need help

Added to documentation?

• README.md
• Dojo Book
• No documentation needed

Checklist

• I've formatted my code (scripts/rust_fmt.sh, scripts/cairo_fmt.sh)
• I've linted my code (scripts/clippy.sh, scripts/docs.sh)
• I've commented my code
• I've requested a review after addressing the comments

Summary by CodeRabbit

• New Features

  • Added support for limiting the maximum number of calls in a single transaction via a new option.
  • Introduced enhanced output formatting for multicall transaction results, displaying each result separately.
  • Expanded model upgrade testing to support and verify upgrades involving nested enums as model keys.
  • Added new entrypoints, events, and views to the world contract ABI, including library registration and owner count functionality.

• Bug Fixes

  • Improved transaction handling by splitting calls into multiple transactions when the maximum call limit is set.

• Tests

  • Significantly expanded test coverage for key upgrade compatibility across structs, enums, arrays, tuples, and nested enum types.
  • Added comprehensive tests for model upgrades involving nested enums.

• Refactor

  • Modularized and clarified old model versions in test helpers for better upgrade testing.
  • Improved import organization and code clarity in several test files.

• Chores

  • Updated various version numbers and configuration values across the project for consistency and release readiness.
  • Refreshed environment and manifest files with updated addresses, class hashes, and configuration paths.

[coderabbitai]

Caution

Review failed

Failed to post review comments.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c876437 and 37a6684.

⛔ Files ignored due to path filters (6)

• Cargo.lock is excluded by !**/*.lock
• crates/dojo/core-cairo-test/Scarb.lock is excluded by !**/*.lock
• crates/dojo/core/Scarb.lock is excluded by !**/*.lock
• examples/simple/Scarb.lock is excluded by !**/*.lock
• examples/spawn-and-move/Scarb.lock is excluded by !**/*.lock
• spawn-and-move-db.tar.gz is excluded by !**/*.gz

📒 Files selected for processing (26)

• .devcontainer/devcontainer.json (1 hunks)
• .github/workflows/bench.yml (1 hunks)
• .github/workflows/release-dispatch.yml (1 hunks)
• .github/workflows/test.yml (5 hunks)
• Cargo.toml (1 hunks)
• bin/sozo/src/commands/auth.rs (3 hunks)
• bin/sozo/src/commands/execute.rs (1 hunks)
• bin/sozo/src/commands/options/transaction.rs (4 hunks)
• crates/dojo/core-cairo-test/Scarb.toml (1 hunks)
• crates/dojo/core-cairo-test/src/tests/helpers/model.cairo (1 hunks)
• crates/dojo/core-cairo-test/src/tests/meta/introspect.cairo (6 hunks)
• crates/dojo/core-cairo-test/src/tests/model/model.cairo (1 hunks)
• crates/dojo/core-cairo-test/src/tests/world/model.cairo (4 hunks)
• crates/dojo/core/Scarb.toml (1 hunks)
• crates/dojo/core/src/meta/introspect.cairo (7 hunks)
• crates/dojo/utils/src/tx/invoker.rs (1 hunks)
• crates/dojo/utils/src/tx/mod.rs (1 hunks)
• crates/macros/merge-options/macro_test/Cargo.toml (1 hunks)
• examples/game-lib/Scarb.toml (1 hunks)
• examples/game-lib/armory/Scarb.toml (1 hunks)
• examples/game-lib/bestiary/Scarb.toml (1 hunks)
• examples/simple/Scarb.toml (1 hunks)
• examples/simple/dojo_sepolia.toml (1 hunks)
• examples/simple/manifest_sepolia.json (11 hunks)
• examples/spawn-and-move/Scarb.toml (1 hunks)
• examples/spawn-and-move/dojo_dev.toml (1 hunks)

🧰 Additional context used

🧠 Learnings (12)

crates/dojo/core-cairo-test/Scarb.toml (2)

Learnt from: glihm
PR: #2633
File: crates/dojo/core/src/world/storage.cairo:484-0
Timestamp: 2024-11-05T04:29:12.288Z
Learning: In the Cairo codebase for the Dojo project, within crates/dojo/core/src/world/storage.cairo, length checks between entity_ids and values are not required in test API functions like write_values_from_ids_test.

Learnt from: glihm
PR: #2633
File: crates/dojo/world/src/contracts/abigen/world.rs:3809-0
Timestamp: 2024-11-05T04:30:12.852Z
Learning: Code in crates/dojo/world/src/contracts/abigen/ is auto-generated and should be excluded from code reviews.

bin/sozo/src/commands/execute.rs (1)

Learnt from: glihm
PR: #2650
File: bin/sozo/src/commands/migrate.rs:64-65
Timestamp: 2024-11-07T13:57:57.616Z
Learning: In the codebase, the use of into() and try_into() for converting TransactionOptions is intentional. Conversions that may fail use try_into(), while those that cannot fail use into(). This approach is appropriate and should be preserved.

Examples:

• try_into() is used in bin/sozo/src/commands/migrate.rs and bin/sozo/src/commands/execute.rs where conversions can fail.
• into() is used in bin/sozo/src/commands/register.rs and bin/sozo/src/commands/auth.rs where conversions are infallible.

.github/workflows/test.yml (2)

Learnt from: steebchen
PR: #2446
File: .github/Dockerfile:24-36
Timestamp: 2024-09-19T19:02:02.747Z
Learning: In the Dockerfile, the pre-caching step in the builder stage is important for caching dependencies and speeding up the build when dependencies don't change.

Learnt from: steebchen
PR: #2446
File: .github/Dockerfile:24-36
Timestamp: 2024-10-11T16:16:06.350Z
Learning: In the Dockerfile, the pre-caching step in the builder stage is important for caching dependencies and speeding up the build when dependencies don't change.

crates/dojo/core-cairo-test/src/tests/model/model.cairo (2)

Learnt from: glihm
PR: #2633
File: crates/dojo/core/src/world/storage.cairo:484-0
Timestamp: 2024-11-05T04:29:12.288Z
Learning: In the Cairo codebase for the Dojo project, within crates/dojo/core/src/world/storage.cairo, length checks between entity_ids and values are not required in test API functions like write_values_from_ids_test.

Learnt from: glihm
PR: #2633
File: crates/dojo/world/src/contracts/abigen/world.rs:3809-0
Timestamp: 2024-11-05T04:30:12.852Z
Learning: Code in crates/dojo/world/src/contracts/abigen/ is auto-generated and should be excluded from code reviews.

bin/sozo/src/commands/auth.rs (1)

Learnt from: glihm
PR: #2650
File: bin/sozo/src/commands/migrate.rs:64-65
Timestamp: 2024-11-07T13:57:57.616Z
Learning: In the codebase, the use of into() and try_into() for converting TransactionOptions is intentional. Conversions that may fail use try_into(), while those that cannot fail use into(). This approach is appropriate and should be preserved.

Examples:

• try_into() is used in bin/sozo/src/commands/migrate.rs and bin/sozo/src/commands/execute.rs where conversions can fail.
• into() is used in bin/sozo/src/commands/register.rs and bin/sozo/src/commands/auth.rs where conversions are infallible.

examples/spawn-and-move/dojo_dev.toml (1)

Learnt from: glihm
PR: #2633
File: crates/dojo/world/src/contracts/abigen/world.rs:3809-0
Timestamp: 2024-11-05T04:30:12.852Z
Learning: Code in crates/dojo/world/src/contracts/abigen/ is auto-generated and should be excluded from code reviews.

crates/dojo/utils/src/tx/mod.rs (3)

Learnt from: glihm
PR: #2650
File: crates/dojo/utils/src/tx/mod.rs:201-272
Timestamp: 2024-11-07T14:43:23.530Z
Learning: In crates/dojo/utils/src/tx/mod.rs, fee token configurations are verified when the fee_config is built, making additional validations in the send_with_cfg methods redundant.

Learnt from: glihm
PR: #2650
File: crates/dojo/utils/src/tx/mod.rs:0-0
Timestamp: 2024-11-07T13:57:19.152Z
Learning: In the send_with_cfg method for ExecutionV1 in crates/dojo/utils/src/tx/mod.rs, FeeConfig::Strk parameters are intentionally ignored for V1 execution, and this is expected behavior.

Learnt from: glihm
PR: #2650
File: bin/sozo/src/commands/migrate.rs:64-65
Timestamp: 2024-11-07T13:57:57.616Z
Learning: In the codebase, the use of into() and try_into() for converting TransactionOptions is intentional. Conversions that may fail use try_into(), while those that cannot fail use into(). This approach is appropriate and should be preserved.

Examples:

• try_into() is used in bin/sozo/src/commands/migrate.rs and bin/sozo/src/commands/execute.rs where conversions can fail.
• into() is used in bin/sozo/src/commands/register.rs and bin/sozo/src/commands/auth.rs where conversions are infallible.

bin/sozo/src/commands/options/transaction.rs (3)

Learnt from: glihm
PR: #2650
File: bin/sozo/src/commands/migrate.rs:64-65
Timestamp: 2024-11-07T13:57:57.616Z
Learning: In the codebase, the use of into() and try_into() for converting TransactionOptions is intentional. Conversions that may fail use try_into(), while those that cannot fail use into(). This approach is appropriate and should be preserved.

Examples:

• try_into() is used in bin/sozo/src/commands/migrate.rs and bin/sozo/src/commands/execute.rs where conversions can fail.
• into() is used in bin/sozo/src/commands/register.rs and bin/sozo/src/commands/auth.rs where conversions are infallible.

Learnt from: glihm
PR: #2650
File: crates/dojo/utils/src/tx/mod.rs:201-272
Timestamp: 2024-11-07T14:43:23.530Z
Learning: In crates/dojo/utils/src/tx/mod.rs, fee token configurations are verified when the fee_config is built, making additional validations in the send_with_cfg methods redundant.

Learnt from: glihm
PR: #2650
File: crates/dojo/utils/src/tx/mod.rs:0-0
Timestamp: 2024-11-07T13:57:19.152Z
Learning: In the send_with_cfg method for ExecutionV1 in crates/dojo/utils/src/tx/mod.rs, FeeConfig::Strk parameters are intentionally ignored for V1 execution, and this is expected behavior.

crates/dojo/core-cairo-test/src/tests/world/model.cairo (2)

Learnt from: glihm
PR: #2633
File: crates/dojo/core/src/world/storage.cairo:484-0
Timestamp: 2024-11-05T04:29:12.288Z
Learning: In the Cairo codebase for the Dojo project, within crates/dojo/core/src/world/storage.cairo, length checks between entity_ids and values are not required in test API functions like write_values_from_ids_test.

Learnt from: glihm
PR: #2633
File: crates/dojo/world/src/contracts/abigen/world.rs:3809-0
Timestamp: 2024-11-05T04:30:12.852Z
Learning: Code in crates/dojo/world/src/contracts/abigen/ is auto-generated and should be excluded from code reviews.

examples/simple/manifest_sepolia.json (1)

Learnt from: glihm
PR: #2633
File: crates/dojo/world/src/contracts/abigen/world.rs:3809-0
Timestamp: 2024-11-05T04:30:12.852Z
Learning: Code in crates/dojo/world/src/contracts/abigen/ is auto-generated and should be excluded from code reviews.

crates/dojo/core-cairo-test/src/tests/meta/introspect.cairo (2)

Learnt from: glihm
PR: #2633
File: crates/dojo/core/src/world/storage.cairo:484-0
Timestamp: 2024-11-05T04:29:12.288Z
Learning: In the Cairo codebase for the Dojo project, within crates/dojo/core/src/world/storage.cairo, length checks between entity_ids and values are not required in test API functions like write_values_from_ids_test.

Learnt from: glihm
PR: #2650
File: bin/sozo/src/commands/migrate.rs:64-65
Timestamp: 2024-11-07T13:57:57.616Z
Learning: In the codebase, the use of into() and try_into() for converting TransactionOptions is intentional. Conversions that may fail use try_into(), while those that cannot fail use into(). This approach is appropriate and should be preserved.

Examples:

• try_into() is used in bin/sozo/src/commands/migrate.rs and bin/sozo/src/commands/execute.rs where conversions can fail.
• into() is used in bin/sozo/src/commands/register.rs and bin/sozo/src/commands/auth.rs where conversions are infallible.

crates/dojo/core-cairo-test/src/tests/helpers/model.cairo (2)

Learnt from: glihm
PR: #2633
File: crates/dojo/core/src/world/storage.cairo:484-0
Timestamp: 2024-11-05T04:29:12.288Z
Learning: In the Cairo codebase for the Dojo project, within crates/dojo/core/src/world/storage.cairo, length checks between entity_ids and values are not required in test API functions like write_values_from_ids_test.

Learnt from: glihm
PR: #2633
File: crates/dojo/world/src/contracts/abigen/world.rs:3809-0
Timestamp: 2024-11-05T04:30:12.852Z
Learning: Code in crates/dojo/world/src/contracts/abigen/ is auto-generated and should be excluded from code reviews.

🔇 Additional comments (39)

crates/dojo/core/src/meta/introspect.cairo (1)

232-266: Ohayo sensei – recursion depth could overflow

is_a_key_upgrade_of is deeply recursive (enum → struct → member → enum …).
A maliciously crafted schema with thousands of nested levels may trigger stack overflow.

If you expect un-trusted schemas, add a recursion-depth guard or switch to an iterative traversal.

examples/game-lib/Scarb.toml (1)

8-8: Ohayo, sensei! Version bump is consistent across the workspace
No issues detected with the update to 1.6.0.

examples/spawn-and-move/Scarb.toml (1)

4-4: Ohayo, sensei! Stable release tag confirmed
The move from -alpha to 1.6.0 aligns with the rest of the repo.

examples/game-lib/armory/Scarb.toml (1)

3-3: Ohayo, sensei! Armory version synced
Looks good; no further action needed.

examples/game-lib/bestiary/Scarb.toml (1)

3-3: Ohayo, sensei! Bestiary bumped cleanly
Change is straightforward and correct.

examples/simple/Scarb.toml (1)

4-4: Ohayo, sensei! Simple example now on 1.6.0
Everything lines up with the workspace release.

crates/macros/merge-options/macro_test/Cargo.toml (1)

3-3: Ohayo sensei — version bump LGTM
Pure metadata change; nothing else to review.

crates/dojo/core/Scarb.toml (1)

6-6: Ohayo sensei — core crate bumped to 1.6.0
Looks consistent with the workspace-level version.

Cargo.toml (1)

32-32: Ohayo sensei — please confirm workspace crate versions are all 1.6.0
I ran the script but saw no output—this could mean either every Cargo.toml is already at 1.6.0 or the check didn’t fire. To be safe, please verify that no member crate is left behind, for example by running:

cargo metadata --no-deps --format-version 1 \
  | jq -r '.packages[].name + " " + .version' \
  | grep -v '^.* 1\.6\.0$'

Any lines printed here indicate crates that still need their version = "1.6.0" bump before cargo publish will succeed.

crates/dojo/core-cairo-test/Scarb.toml (1)

6-6: Ohayo sensei — test crate version updated
Change is straightforward; no further action needed.

examples/spawn-and-move/dojo_dev.toml (1)

71-71: Ohayo sensei — double-check updated world_address is actually deployed

Only the address has changed. Please confirm that
0x137a764faf4e61963b00fcd67cbae5ffc664bd50763799643851e50f9343d8d
matches the contract emitted by the latest deploy script; mismatched
addresses silently break the example.

examples/simple/manifest_sepolia.json (4)

83-86: Resource enum extended — verify downstream decoding

Adding the Library variant changes the discriminant order. Any Rust /
TS client that deserialises by numeric index rather than by
name will break. Make sure SDKs use the generated enum names or bump a
major version.

---

1018-1038: Event LibraryRegistered — nice addition

LGTM; fields are keyed correctly and mirrored in the umbrella Event
enum.

Also applies to: 1281-1284

---

1331-1333: Address / class-hash churn

All hashes & addresses bumped. Ensure the manifests used by indexers
(or any hard-coded front-ends) are regenerated to avoid orphaned
components.

Also applies to: 1590-1591, 1765-1767, 2027-2034, 2041-2048

---

14-15: Ohayo sensei — unable to locate the register_library implementation

I couldn’t find a Clarity definition for this entrypoint, so please manually verify:

• That register_library enforces proper owner/admin checks (to prevent untrusted accounts from polluting the registry).
• Whether you plan to add a max_calls or batching parameter (to avoid hitting calldata limits on bulk registrations).

Location to review:

• examples/simple/manifest_sepolia.json, lines 14–15 ("register_library")

.github/workflows/bench.yml (1)

22-22: Bench workflow image bumped — smoke-run required

Please run one manual workflow to ensure the new image still contains
cargo bench (there were linker issues in alpha 1 → alpha 2 for some
folks).

.github/workflows/test.yml (1)

70-76: Ohayo sensei — version mismatch between CI image and Katana download

Containers now pull dojo-dev:v1.6.0-alpha.2, yet the script still fetches katana_v1.6.0-alpha.1. Please verify these versions are intended to diverge; if not, bump Katana to alpha.2 for consistency.

bin/sozo/src/commands/execute.rs (1)

172-182: Ohayo sensei — implementation looks good

Handling multiple TransactionResults is correct and the borrow-then-own pattern is safe here. No further issues spotted.

crates/dojo/utils/src/tx/mod.rs (1)

43-58: Ohayo sensei — clean, backward-compatible extension

New max_calls seamlessly integrates with existing config; default None preserves prior behaviour. Nice!

bin/sozo/src/commands/auth.rs (2)

380-386: Ohayo sensei — multi-result printing is correct

Iteration over the returned vector is straightforward and maintains previous output style. Looks solid.

---

600-603: Ohayo sensei — consistent pattern reused

Same pattern applied in owners & writers helpers; keeps behaviour uniform. No concerns.

Also applies to: 644-647

bin/sozo/src/commands/options/transaction.rs (4)

41-45: Ohayo sensei! LGTM on the new max_calls field.

The field declaration is well-structured with clear documentation and appropriate typing. The Option<usize> type makes perfect sense for an optional batch size limit.

---

65-65: Field propagation looks solid, sensei!

The max_calls field is correctly passed through to the TxnAction::Send variant, maintaining consistency with the existing code pattern.

---

80-80: Clean conversion implementation, sensei!

The max_calls field is properly propagated in the TryFrom conversion, maintaining consistency with the existing pattern.

---

99-99: Test coverage looks great, sensei!

The test updates properly verify that the max_calls field is correctly converted through the TryFrom implementation. The test value and assertion pattern are consistent with the existing test structure.

Also applies to: 107-107

crates/dojo/core-cairo-test/src/tests/model/model.cairo (1)

1-3: Import reordering looks good, ohayo sensei!

The reorganization of imports maintains functionality while improving consistency across the test suite.

crates/dojo/core-cairo-test/src/tests/helpers/model.cairo (5)

1-17: Well-structured enum definitions for upgrade testing, ohayo!

The new MyEnum and MyNestedEnum types with introspection traits provide a solid foundation for testing the nested enum key upgrade scenarios mentioned in the PR objectives.

---

19-46: Smart approach to avoid contract name conflicts, sensei!

Using Introspect trait without dojo::model attribute prevents duplicate contract names while still providing the necessary introspection capabilities for testing model upgrades.

---

48-57: Helper function provides consistent layout for test scenarios

The fixed layout structure correctly represents the old model's memory layout for upgrade testing.

---

337-412: Excellent hardcoded schema for nested enum testing!

The m_OldModelWithNestedEnumKey contract provides a detailed schema representation of the old nested enum structure, which perfectly aligns with the PR's objective to test enum key upgrades. The comments clearly explain the type hierarchy.

---

147-150: No action needed: empty layout is intentional for bad‐layout test

Ohayo sensei! The m_OldFooModelBadLayoutType’s layout() returning Fixed([].span()) is deliberately invalid—this drives the should_panic in test_upgrade_model_with_bad_layout_type, ensuring an upgrade failure for bad layouts. No changes required here.

crates/dojo/core-cairo-test/src/tests/meta/introspect.cairo (8)

1-2: Clean refactoring of the enum helper function!

The direct return from the loop break eliminates redundant code and improves readability.

Also applies to: 141-151

---

427-433: Consistent validation of primitive key upgrades, ohayo!

Good addition to ensure primitive types follow the same upgrade rules for both regular and key upgrades.

---

651-727: Comprehensive struct key upgrade testing!

Excellent coverage of all struct upgrade scenarios, sensei. The test correctly enforces that new members are not allowed in key upgrades, which is a crucial distinction from regular upgrades.

---

729-787: Thorough enum key upgrade validation!

The tests properly validate that enum key upgrades allow new variants while enforcing upgrade rules on existing variant data. The Option<T> special case handling is a nice touch.

---

789-800: Array key upgrade tests are on point!

Correctly validates that array item types must follow key upgrade rules.

---

802-823: Important tuple size constraint validation, ohayo sensei!

Excellent test coverage ensuring tuple key upgrades maintain the same size - both smaller and larger tuples are correctly rejected. This is a key distinction from regular tuple upgrades.

---

638-641: ByteArray upgrade tests confirm always-allowed behavior

Both tests correctly validate that ByteArray types can always be upgraded to themselves.

Also applies to: 825-828

---

831-985: Exceptional nested enum key upgrade testing!

This comprehensive test beautifully validates the recursive application of enum key upgrade rules to nested structures. The three test cases cover all critical scenarios for nested enum upgrades.

Walkthrough

Ohayo sensei! This update introduces a max_calls option for multicall transactions, enabling splitting large multicalls into multiple transactions with chunked execution and result handling. It also adds comprehensive type upgrade compatibility checks for model keys, expands related tests, and updates several version numbers and configuration files across the repository.

Changes

Files/Groups	Change Summary
.devcontainer/devcontainer.json .github/workflows/bench.yml .github/workflows/release-dispatch.yml .github/workflows/test.yml	Updated Docker image versions from v1.6.0-alpha.1 to v1.6.0-alpha.2 in devcontainer and workflow configs.
Cargo.toml crates/dojo/core-cairo-test/Scarb.toml crates/dojo/core/Scarb.toml examples/game-lib/Scarb.toml examples/game-lib/armory/Scarb.toml examples/game-lib/bestiary/Scarb.toml examples/simple/Scarb.toml examples/spawn-and-move/Scarb.toml crates/macros/merge-options/macro_test/Cargo.toml	Updated package version numbers from pre-release to stable 1.6.0 (or from earlier pre-releases to 1.6.0).
examples/simple/dojo_sepolia.toml examples/spawn-and-move/dojo_dev.toml	Updated configuration values (world seed, keystore path, and world address).
examples/simple/manifest_sepolia.json	Updated manifest with new class hashes, addresses, added entrypoints, ABI functions, events, and resource variants.
bin/sozo/src/commands/auth.rs bin/sozo/src/commands/execute.rs	Refactored multicall result handling to iterate and print multiple transaction results.
bin/sozo/src/commands/options/transaction.rs crates/dojo/utils/src/tx/mod.rs	Added max_calls field to transaction options/config, updated related methods and tests.
crates/dojo/utils/src/tx/invoker.rs	Refactored multicall to support chunking calls by max_calls, returning multiple transaction results.
crates/dojo/core/src/meta/introspect.cairo	Added is_a_key_upgrade_of method for key upgrade compatibility, implemented recursively for types, and refactored upgrade logic.
crates/dojo/core-cairo-test/src/tests/helpers/model.cairo	Refactored test models into contracts, added enum types, updated deployment and test setup for model upgrades.
crates/dojo/core-cairo-test/src/tests/meta/introspect.cairo	Expanded and reorganized tests for key upgrade compatibility across types (structs, enums, arrays, tuples, byte arrays, nested).
crates/dojo/core-cairo-test/src/tests/world/model.cairo	Added nested enum types, a new model, and a test for model upgrades involving nested enum keys.
crates/dojo/core-cairo-test/src/tests/model/model.cairo	Reordered import statements only.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant CLI
    participant Invoker
    participant Network

    User->>CLI: Initiate multicall with max_calls option
    CLI->>Invoker: multicall()
    alt max_calls is set
        Invoker->>Invoker: Chunk calls by max_calls
        loop For each chunk
            Invoker->>Network: Send transaction for chunk
            Network-->>Invoker: Return TransactionResult
        end
        Invoker-->>CLI: Return Vec<TransactionResult>
    else No max_calls
        Invoker->>Network: Send all calls in one transaction
        Network-->>Invoker: Return TransactionResult
        Invoker-->>CLI: Return Vec<TransactionResult> (single element)
    end
    CLI->>User: Print each TransactionResult

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• fix(utils/invoker): add split for big multicalls #3284: Introduces a similar max_calls option for multicall handling and updates result processing, directly related at the code level.
• chore(devcontainer): update image: v1.6.0-alpha.2 #3278: Updates the same Docker image versions in devcontainer and workflow files, overlapping with this PR’s configuration changes.
• release(prepare): v1.6.0-alpha.2 #3276: Performs related version bump changes for packages and workflows, sharing overlapping version update logic.

Suggested labels

contributor

Suggested reviewers

• glihm

Note

⚡️ Unit Test Generation - Beta

CodeRabbit's unit test generation is now available in Beta! Automatically generate comprehensive unit tests for your code changes, ensuring better test coverage and catching edge cases you might miss. Our AI analyzes your code structure and creates tests that follow best practices and your project's testing patterns. Learn more here, or just try it under ✨ Finishing Touches.

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch 1.6.0-fix_upgrade_with_enum_keys

---

🪧 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>, please review it.
  • Explain this complex logic.
  • 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 explain this code block.
  • @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 gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @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.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

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)

• @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 generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai generate unit tests to generate unit tests for this 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.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

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.

[glihm]

Thank you for the double PR to ensure we can release that on 1.6.0 stable release before proc macros.

I've tested with pistols use case too, and worked as intended. 👍