fix(core): FixedArray Ty/Layout improvements

[remybar]

FixedArray support has been added recently but it has been added in the middle of Ty and Layout enums.

To avoid any issue in case of enum serializing, it is better to add this FixedArray variant at the end of these enums.

Then, to ease FixedArray processing by Torii, Layout and Ty now use (Span<Layout>, u32) / (Span<Ty>, u32) instead of Span<(Layout, u32)> / Span<(Ty, u32)> .

Summary by CodeRabbit

• Chores
  • Updated example configuration and manifest metadata (world addresses, class hashes, contract addresses).
  • Updated test policy data with new target addresses and added upgrade policies.
  • Adjusted internal representation of fixed-size arrays and related serialization mappings — no changes to public APIs or visible behavior.
• Tests
  • Updated and adapted tests to match the internal representation changes.

[coderabbitai]

Walkthrough

Ohayo sensei! This change refactors the FixedArray representation across crates from a span/vector of (item, size) pairs to a tuple (Span<Vec<Item>>, size) or (Vec<Item>, size), and updates pattern-matching, serialization discriminants, tests, manifests, and example configs accordingly.

Changes

Cohort / File(s)	Change Summary
Core enum defs & introspection crates/dojo/core/src/meta/introspect.cairo, crates/dojo/core/src/meta/layout.cairo, crates/dojo/types/src/schema.rs	FixedArray / FixedSizeArray variants changed from Span/Vec<(T, u32)> to (Span/Vec<T>, u32). Pattern matching and accessors updated.
Storage implementation updates crates/dojo/core/src/storage/layout.cairo, crates/dojo/core-tests/src/tests/storage/layout.cairo	Storage read/write/delete APIs and tests updated to accept and index the new (Span<Layout>, u32) shape instead of popping tuple spans.
Introspect tests & core-tests crates/dojo/core-tests/src/tests/meta/introspect.cairo	Test constructions adjusted to build FixedArray using (array![inner].span(), size) instead of a span of tuples.
World & abigen serialization changes crates/dojo/world/src/contracts/abigen/model.rs, crates/dojo/world/src/contracts/abigen/world.rs, crates/dojo/world/src/contracts/model.rs	Abigen/model/world updated to new FixedArray payload type (Vec<T>, u32) and adjusted CairoSerde discriminant mapping/serialize/deserialize paths; parsing logic updated to construct tuple-based variant.
sozo ops formatting/usage updates crates/sozo/ops/src/model.rs	All pattern matches and helpers updated to destructure (items, length) and access inner item via items[0] rather than previous pair shape.
Examples / manifests / policies examples/spawn-and-move/dojo_dev.toml, examples/spawn-and-move/manifest_dev.json, bin/sozo/tests/test_data/policies.json	Updated world address, class hashes, contract/model/event addresses, and policy target addresses; no API signature changes.

Sequence Diagram(s)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat(dojo-core): make the schema upgrade less strict #2925 — touches meta/introspect Ty::FixedArray handling and comparison logic.
• fix(core): fix upgrade with enum keys #3289 — updates Ty comparison and FixedArray pattern handling in introspection code.
• opt-refactor(torii-core): complete sql schema refactor #2718 — changes FixedArray representation and serialization/deserialization that affect model/schema parsing.

Suggested labels

contributor

Suggested reviewers

• glihm

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-ty_and_layout_order

---

🪧 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.
  • 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.
• 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 the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

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

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

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.

Status, Documentation and Community

• Visit our Status Page to check the current availability of CodeRabbit.
• 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.

[kariy]

i think we should add some sanity checks to make sure the size of Span<Ty> is exactly the same as the size in the tuple ie Ty::FixedSizeArray((Span<Ty>, u32)).

[remybar]

i think we should add some sanity checks to make sure the size of Span<Ty> is exactly the same as the size in the tuple ie Ty::FixedSizeArray((Span<Ty>, u32)).

But it's not the case on dojo-core side. The Span always contains only one item which is the Ty of array items. But on Torii it seems that the Span is then used to store values.

[kariy]

i think we should add some sanity checks to make sure the size of Span<Ty> is exactly the same as the size in the tuple ie Ty::FixedSizeArray((Span<Ty>, u32)).

But it's not the case on dojo-core side. The Span always contains only one item which is the Ty of array items. But on Torii it seems that the Span is then used to store values.

Ok yes you're right! I keep forgetting about that. It is pretty confusing when the type definition is inconsistent with what it's trying to represent.

[remybar]

i think we should add some sanity checks to make sure the size of Span<Ty> is exactly the same as the size in the tuple ie Ty::FixedSizeArray((Span<Ty>, u32)).

But it's not the case on dojo-core side. The Span always contains only one item which is the Ty of array items. But on Torii it seems that the Span is then used to store values.

Ok yes you're right! I keep forgetting about that. It is pretty confusing when the type definition is inconsistent with what it's trying to represent.

Yes, I agree! That's why I proposed to try to use a Box instead of a Span but it would break on Torii side 🫤

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

crates/dojo/world/src/contracts/abigen/model.rs (2)

484-492: Ty: FixedArray tuple payload and discriminants look correct

Ohayo sensei — Ty::FixedArray((Vec, u32)) with ByteArray=5 and FixedArray=6 is consistently reflected across size/serialize/deserialize branches and uses the tuple serde helpers.

Given the ongoing confusion discussed in the PR about whether the inner Vec represents a single element type (core) vs values (Torii), consider adding a short doc comment in the non-generated API surface (e.g., types/schema.rs or a README) clarifying the semantics expected by core vs Torii. Avoid putting checks in generated files.

Also applies to: 497-507, 541-546, 566-569

---

393-393: Optional: Add sanity checks for FixedArray inner Vec length outside generated code

Ohayo sensei — if core guarantees the inner Span/Vec holds exactly one Ty/Layout (the element type), a lightweight runtime assert (or constructor) in the hand-written layers could prevent misuse: e.g., enforce vec.len() == 1 when constructing FixedArray on the core path.

I can sketch a small helper/newtype for FixedArray element type to centralize the invariant if you’d like.

Also applies to: 491-491

crates/dojo/world/src/contracts/abigen/world.rs (1)

3681-3689: Nit: Consider documenting the meaning of the inner Vec for FixedArray in consumer docs

Ohayo sensei — since abigen maps Span to Vec, a note in user-facing docs clarifying whether Vec is “element type (len=1)” vs “values” would save future head-scratching. Keep generated code unchanged.

Also applies to: 3694-3703

📜 Review details

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

📥 Commits

Reviewing files that changed from the base of the PR and between b10d320 and e0554ec.

⛔ Files ignored due to path filters (1)

• spawn-and-move-db.tar.gz is excluded by !**/*.gz

📒 Files selected for processing (3)

• crates/dojo/world/src/contracts/abigen/model.rs (8 hunks)
• crates/dojo/world/src/contracts/abigen/world.rs (4 hunks)
• crates/sozo/ops/src/model.rs (6 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• crates/sozo/ops/src/model.rs

🔇 Additional comments (4)

crates/dojo/world/src/contracts/abigen/model.rs (2)

386-394: FixedArray moved to end and payload switched to tuple — LGTM

Ohayo sensei — placing FixedArray last and using (Vec, u32) removes mid-enum insertion churn and matches the PR intent.

---

399-409: Ohayo sensei! Discriminants & shapes are in sync across crates

All the updates landed correctly—ByteArray=4, Enum=5, FixedArray=6—across size, serialize, and deserialize for both Layout and Ty. FixedArray now consistently uses <(Vec<Layout>, u32)>::cairo_* (or <(Vec<Ty>, u32)> for Ty) in:

• core/src/meta/{layout,introspect}.cairo (FixedArray: (Span<…, u32))
• crates/dojo/world/src/contracts/abigen/model.rs & world.rs
  – size: +1 on <(Vec<…, u32)>::cairo_serialized_size
  – serialize: prefix with 6usize then <(Vec<…, u32)>::cairo_serialize
  – deserialize: arm 6usize → FixedArray(<(Vec<…, u32)>::cairo_deserialize…)

No stale Vec<(Layout, u32)>, Span<(Layout, u32)>, or old tuple shapes remain. LGTM!

crates/dojo/world/src/contracts/abigen/world.rs (2)

3681-3689: Layout: FixedArray moved to end with tuple payload — aligned with core

Ohayo sensei — Variant order and the new (Vec, u32) payload match the PR objective and core Cairo definitions.

---

3694-3703: Layout discriminants remapped (ByteArray=4, Enum=5, FixedArray=6) — wire format stable

Ohayo sensei — I ran the scans and confirmed:

• No Vec<(Layout, u32)> usages remain in crates/dojo/world.
• The Cairo Layout enum in crates/dojo/core/src/meta/layout.cairo lists ByteArray as 4, Enum as 5, FixedArray as 6 with the correct (Span<Layout>, u32) payload.

All clear to merge!