Repository navigation
fix(storage): connect to a host's shared storage service by name - #11
Conversation
Tiny Sweeper review
Last completed reportTiny Sweeper reviewReviewed head: Verdict: Ready for maintainer review · Priority: none Diagnostics and supporting detailsFull summaryPull request purpose (title): fix(storage): connect to a host's shared storage service by name. The pull request titled "fix(storage): connect to a host's shared storage service by name" intends to let `storage::open` accept a host's shared storage service name (`tinystoragedrivers_busproxy::HOST_NAME`) and connect via `connect_storage`, while all other names still go through `connect_storage_at`, and to update the release verification example to serve memory storage through host callbacks. However, the reviewed diff contains only two new tests in `crates/tinyeventqueues/src/tinybus_module/storage_tests.rs`; the described production fix in `storage.rs` and the `examples/verify_github_release.rs` change are absent. The description itself notes the first push carries only the tests so CI shows them failing against unchanged code. Review snapshot
Completeness: Complete What changedOnly `crates/tinyeventqueues/src/tinybus_module/storage_tests.rs` is changed, adding 28 lines and deleting 0. Two `#[tokio::test]` functions were added: `the_shared_storage_service_name_reaches_the_host_serving_it` (lines 130–140), which builds a rig with storage served, connects a module, calls `open(module, Some(tinystoragedrivers_busproxy::HOST_NAME))`, and asserts the result is `Ok`; and `the_shared_storage_service_name_fails_setup_when_nobody_serves_it` (lines 142–156), which builds a rig without storage served, calls the same `open`, asserts the result is an error, and asserts the error string contains `"storage_callback"`. No production code, dependency, or CI change is present in the reviewed diff. Features
TestsNo supported feature-to-test mapping was produced. Test execution is not inferred. FindingsNo active actionable findings. Before mergeNone. Agent review detailscritique
security
tests
commits
description
Evidence and run details
|
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Comment |
Problem
v0.2.0 can't be loaded by a host that serves one storage service for every module, which is how openhuman serves storage.
storage::openhands everystorage_callbacktotinystoragedrivers_busproxy::connect_storage_at. That function refuses any destination that isn't a unique bus name ("storage callback destination must be a unique bus name"). openhuman passes the shared service's well-known name,ai.tinyhumans.tinystorage.Storage, which is the same value TinyMCP already accepts. So the module faults at setup.Fix
storage::opentreats exactly that name (tinystoragedrivers_busproxy::HOST_NAME) as the shared service and connects withconnect_storage. Every other name still goes throughconnect_storage_atas-is. This follows TinyMCP'sbus_provider.There is still no fallback:
an_unadmitted_storage_destination_does_not_fall_back_to_global_storageis unchanged).Release verification
examples/verify_github_release.rsloaded the release with an empty config and no storage, so v0.2.0's post-publish step faulted even though the artifact is fine. It now serves a memory storage host through host callbacks and passes that binding'sstorage_callback, the same wayverify_module.rsdoes.Tests
the_shared_storage_service_name_reaches_the_host_serving_it: the new branch. It fails on main, where the name is refused as not unique.the_shared_storage_service_name_fails_setup_when_nobody_serves_it: no fallback when nobody serves the shared name.The first push carries only the tests, so CI shows them failing against unchanged code. The fix follows in the next push.
Refs tinyhumansai/openhuman#8326