Repository navigation
Support host-owned storage in metagame APIs - #166
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
claude-opus-5-5-medium Code Review: 0f9d64flgtm |
gpt-6.1-sol-high Code Review: 0f9d64flgtm |
claude-opus-5-5-medium Code Review: 0f9d64fI've finished reading the scoped diff and the store code behind it. One low-severity gas finding remains. [LOW] packages/metagame/src/leaderboard/api.cairo:29 - pub trait Configuration<T> {
fn leaderboard_config(self: @T, context_id: u64) -> LeaderboardStoreConfig;
fn leaderboard_game_address(self: @T, context_id: u64) -> ContractAddress {
Self::leaderboard_config(self, context_id).game_address
}
}In I also checked the PR's assumptions; no other actionable findings:
|
gpt-6.1-sol-high Code Review: 0f9d64flgtm |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
claude-opus-5-5-medium Code Review: ca5d8f2lgtm |
gpt-6.1-sol-high Code Review: ca5d8f2lgtm |
claude-opus-5-5-medium Code Review: ca5d8f2Quick update: I've finished reading the scoped diff. I didn't find anything that needs a change. lgtm |
gpt-6.1-sol-high Code Review: ca5d8f2lgtm |
claude-opus-5-5-medium Code Review: fea50c0[LOW] README.md:61 - The new paragraph says host-owned storage applies only to "Leaderboard and entry-requirement APIs". The head commit (fea50c0) also adds Leaderboard, registration, entry-requirement, entry-fee and prize APIs also
support application-owned storage without embedding their components. See
[host-owned storage](packages/metagame/HOST_STORAGE.md) for configuration
providers, optional component adapters and upgrade compatibility. |
gpt-6.1-sol-high Code Review: fea50c0lgtm |
claude-opus-5-5-medium Code Review: fea50c0lgtm I found no actionable issues in the scoped
|
gpt-6.1-sol-high Code Review: fea50c0lgtm |
claude-opus-5-5-high Code Review: 382a23flgtm |
gpt-6.1-sol-xhigh Code Review: 382a23flgtm |
claude-opus-5-5-high Code Review: 382a23flgtm |
gpt-6.1-sol-xhigh Code Review: 382a23flgtm |
claude-opus-5-5-high Code Review: a541596lgtm |
gpt-6.1-sol-xhigh Code Review: a541596lgtm |
claude-opus-5-5-high Code Review: a541596lgtm |
gpt-6.1-sol-xhigh Code Review: a541596lgtm |
Applications can now use leaderboard, entry-requirement, registration, entry-fee and prize APIs with their own storage, while retaining the standard components as compatible defaults.
Adds embeddable views and shared internal operations over
Store<T>, configuration providers and optional adapters to original component maps. Apps can pack fields across modules, derive configuration or retain selected deployed maps without maintaining their own copies of interface or transfer/claim logic. Standard components delegate to these APIs; their layouts, signatures, aliases, initialization, hooks and validation messages remain intact. Hosts continue to enforce authorization, lifecycle eligibility, entitlement and reentrancy protection.Independent host examples combine registration/submission/ban state with fee refund history, and combine small prize metadata fields. Tests verify that replacing a registration preserves its refund claim, contexts stay isolated, packed writes preserve neighboring fields, and token transfers and extension dispatch behave consistently. Usage and benchmark documentation explains partial forwarding, upgrade compatibility and packing limits: the complete 165-bit entry-fee data and 88-bit distribution cannot fit together in one felt.
The matched registration → submission → refund-marking example saves 8.72% L2 gas and 25% L1 data gas (2,373,361 → 2,166,402 L2; 384 → 288 L1 data). Both paths make four write syscalls; the combined layout changes fewer distinct slots. This is a local fixture benchmark, not a tournament-wide saving or charged network fee.
Validation: all 479 metagame tests pass, including 34 host/adapter cases and existing fuzz tests; the whole workspace builds; formatting and diff checks pass. The original implementation coverage measurement (fea50c0), excluding test directories, improves from 1,247/1,389 (89.78%) on ca5d8f2 to 1,465/1,546 (94.76%), using cairo-coverage 0.6.1 and unioned source-line hits. Registration is 100%, entry fee 93.36%, prize 96.67% under that same method.
Budokan PR352 pins the implementation revision
fea50c0and now targets a fresh deployment. Its current candidate passes 360 Budokan tests with 2 existing skips, plus 165 bracket and 19 viewer release cases; its production Budokan CASM size is 78,286 felts. Budokan retains its registration and claim maps; the combined layouts are opt-in. The review follow-ups update documentation and tests without changing production contract code.This branch builds on 5e48f22 to keep the initial Budokan dependency compatible with its deployed game-token API; unrelated newer game-status changes are not included in that pin. No declarations or upgrade transactions.
Review follow-up: the README now names all five APIs. Two new ERC721 deposit cases verify the sponsor, host destination, full-width token ID and stored record through both host storage and component adapters. Matched prize-source coverage increases from 364/390 to 366/390; the new prize API increases from 65/69 to 67/69 executable lines. The two remaining uncovered API lines are existing unreachable extension-variant fallback branches:
get_token_recordalways constructs a token variant. The leaderboard narrow-getter finding was already fixed in ca5d8f2.