Repository navigation
fix(modules): re-pin TinyBox to v0.2.1 - #8324
Conversation
Picks up tinybox#124: on host-managed storage the module declares only its current collections and runs no in-module v1 migration, so it no longer trips the storage host's `schema-is-host-only` guard and shell command resources open again. Bumps the registry record version, release URL, archive names, and all 17 platform sha256s to the published v0.2.1 release (verified against its checksum.toml). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing: 1
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 999cc16433
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| version: "0.2.0", | ||
| release_url: "https://github.com/tinyhumansai/tinybox/releases/tag/v0.2.0", | ||
| version: "0.2.1", | ||
| release_url: "https://github.com/tinyhumansai/tinybox/releases/tag/v0.2.1", |
There was a problem hiding this comment.
Advance the TinyBox gitlink with the release pin
In any checkout with recursive submodules initialized, vendor/tinybox still resolves to b0b5969ab6d04b64c478e1f012b6af2ac53fc171, which the preceding pin identifies as the v0.2.0 tag, while scripts/ci/check-module-pins.mjs requires its git describe result to equal this record's version and TinyBox has no exemption. Consequently this v0.2.1 pin fails the module-pin gate, and local source/linked modes continue compiling the v0.2.0 implementation containing the migration this change is intended to remove; check out and stage the v0.2.1 gitlink as part of the re-pin.
AGENTS.md reference: AGENTS.md:L670-L674
Useful? React with 👍 / 👎.
| object_path: tinybox_bus::OBJECT_PATH, | ||
| version: "0.2.0", | ||
| release_url: "https://github.com/tinyhumansai/tinybox/releases/tag/v0.2.0", | ||
| version: "0.2.1", |
There was a problem hiding this comment.
Refresh the TinyBox manifest test for v0.2.1
With modules enabled (it is a default feature and the gate-contract-tests-features lane explicitly runs modules::registry::), tinybox_registry_matches_the_published_v020_release_manifest in registry_tests.rs:118-221 still asserts the v0.2.0 version, URL, and all 17 old archives and digests. This change therefore fails immediately at assert_eq!(record.version, "0.2.0"); update and rename that manifest fixture alongside these pins.
Useful? React with 👍 / 👎.
#8324 moved the registry record to v0.2.1 but left the submodule on v0.2.0 and the release-manifest test asserting v0.2.0, so the module pin gate and that test were red on main. - vendor/tinybox -> fc34d28da8 (tag v0.2.1) - registry_tests: the TinyBox manifest test asserts the v0.2.1 version, URL and all 17 digests, taken from the GitHub release assets - Cargo.lock and crates/openhuman-app/Cargo.lock: tinybox path crates 0.2.0 -> 0.2.1 (the only manifest changes besides tokio features)
Summary
Re-pin the TinyBox module from v0.2.0 to v0.2.1 in the module registry.
v0.2.1 ships tinyhumansai/tinybox#124: on a host-managed storage port (storage reached over the bus, as the harness serves it), TinyBox now only re-declares its current collections and runs no in-module v1 migration. On v0.2.0 the module's
migrations::preparealso ensured the v1 collectionstinybox_boxes/tinybox_jail_index, which the storage host refuses withschema-is-host-only(the host owns the schema and only answers declarations in the module's grant). That failure stopped the box store from opening, so every shell command resource failed ("TinyBox could not create a command resource"). With v0.2.1 the host's own importer owns the legacy migration and the module stays within its grant, so shell works again.Updates the registry record's
version,release_url, the 17 platform archive names, and all 17sha256values.Related issue
Follows tinyhumansai/tinybox#124 (merged, released as v0.2.1). Prior pin was #8320 (v0.2.0).
API or behavior changes
None in OpenHuman. Pin/metadata only. Restores shell execution through TinyBox on hosts that serve module storage over the bus.
Validation
sha256values verified byte-for-byte against the v0.2.1 release's publishedchecksum.toml(17/17 match, none missing).rustfmt --edition 2024 --checkclean on the edited file.served=Release, makes exactly its 5 grantedEnsureCollectioncalls (all answered by the host, zeroschema-is-host-only), and runs shell commands successfully (crack-7z-hash solved).Tests
No new tests — registry data change. Existing module-loading and storage-host tests cover the grant/
schema-is-host-onlybehavior.Documentation
None needed.
Checklist
#[allow(...)],#[ignore], or relaxed lints.envcontents in the diff or the description🤖 Generated with Claude Code