Holochain 0.6.1 upgrade — sweettest tests, UI dep modernization#56
Open
ThetaSinner wants to merge 11 commits intomainfrom
Open
Holochain 0.6.1 upgrade — sweettest tests, UI dep modernization#56ThetaSinner wants to merge 11 commits intomainfrom
ThetaSinner wants to merge 11 commits intomainfrom
Conversation
- actions/checkout v4 -> v6 - actions/setup-go v5 -> v6 - cachix/cachix-action v16 -> v17 - peter-evans/create-pull-request v7 -> v8 - Align Nix install URL to 2.34.6 across all workflows - Remove duplicate Swatinem/rust-cache entry in cli-test job
Workspace and checked_cli bumps: - anyhow 1.0.81 -> 1.0.102 - chrono 0.4.34 -> 0.4.44 - clap 4.5.2 -> 4.6.1 - ed25519-dalek 2.1.1 -> 2.2.0 - indicatif 0.18 -> 0.18.4 - minisign 0.8 -> 0.9.1 - minisign-verify 0.2.1 -> 0.2.5 - proc-ctl 0.4.0 -> 0.4.1 - rand 0.9/0.10 -> 0.10.1 (aligned across workspace and CLI; added thread_rng feature) - regex 1.10.3 -> 1.12.3 - reqwest 0.13 -> 0.13.2 - rpassword 7.3.1 -> 7.4.0 - tempfile 3.10.1 -> 3.27.0 - tokio 1.37.0 -> 1.52.1 - url 2.5.0 -> 2.5.8 - warp 0.4 -> 0.4.2 Migrate fetch zome rand call sites: choose_multiple -> sample. Holochain crates pinned at 0.6.1-rc.8 (no change).
….6.1 Workarounds for unrelaxable transitive pins in the Holochain dev-dep chain: - Pin sha1, sha2, digest down to versions where the iroh-base /pkarr -> ed25519-dalek 3.0.0-pre.1 -> curve25519-dalek 5.0.0-pre.1 chain compiles (curve25519-dalek-5.0.0-pre.1 references digest::crypto_common, removed at digest 0.11.0-rc.11+). - Enable transport-tx5-backend-go-pion on the holochain dev-dep so kitsune2's Builder gets its required transport field set (avoids the iroh-holochain crypto_box/chacha20 pin chain). - Enable warp's server feature now that warp 0.4 dropped default features. Update test source for HC 0.6.1 admin API drift: - InstallAppPayload: drop allow_throwaway_random_agent_key - InterfaceDriver::Websocket: add danger_bind_addr: None - AppStatusFilter::Running -> Enabled - warp::serve(...).bind_ephemeral(...) replaced with explicit TcpListener::bind + .incoming()
Tryorama is no longer maintained for Holochain 0.6.x, so the JS integration suite is replaced with a Rust sweettest crate under tests/. Three cross-agent delete-link tests are #[ignore]d for the same reason upstream gates its own consistency tests on transport-iroh — the default tx5/go-pion backend can't reliably deliver the must_get_agent_activity deps the validators require.
Aligns the three types crates with the rest of the workspace, which is already on edition 2024 in the zome and CLI crates.
Bumps the UI to a current toolchain: - TypeScript 4 -> 6 (moduleResolution switched to Bundler) - vue-tsc 1 -> 3 - Vite 4 -> 8 with @vitejs/plugin-vue 6 and vite-plugin-checker 0.13 - ESLint 8 -> 10, migrated to flat config (eslint.config.mjs) - @vue/eslint-config-typescript 12 -> 14, eslint-plugin-vue 9 -> 10 - Vue 3.2 -> 3.5, vue-router 4 -> 5, pinia 2 -> 3 - @holochain/client 0.19 -> 0.20 (matches Holochain 0.6.x) - date-fns 3 -> 4, @fortawesome/* 6 -> 7, postcss/autoprefixer/cssnano refresh - tailwindcss 3 -> 4, daisyui 4 -> 5: CSS-first config via @plugin and @source directives in src/style.css; the daisyui plugin is loaded via the explicit "daisyui/index.js" path because Tailwind's module resolver picks daisyui's "browser" field (./daisyui.css) over "main" otherwise. Source-level adaptations: - Fix 'catch (e: any)' -> 'catch (e: unknown)' for the new strict ruleset. - Drop unused SignalType import from signals.ts. - Replace inject('client') with a module-level Ref in holochain-client.ts. Pinia 3's runWithContext only sees app-level provides, so the previous component-scoped provide('client', ...) returned undefined when injected from setup stores, breaking the watch source.
- Rename "Run Tryorama tests" -> "Run integration tests" to match the new sweettest crate. - Drop ubuntu-latest from the cli-test matrix; the nix-based test job already runs the same npm run test:cli on Linux.
📝 WalkthroughWalkthroughThis pull request performs comprehensive toolchain and dependency upgrades while migrating the test infrastructure from TypeScript/Vitest to Rust-based integration tests. It updates Rust editions to 2024, bumps Holochain and related crate versions, refactors link-query patterns in zomes, and transitions the UI to use a shared holochain client reference instead of Vue dependency injection. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant UIApp as UI App
participant HoloClient as Holochain Client (Shared Ref)
participant ZomeCall as Zome (Coordinator)
participant DHT as DHT
User->>UIApp: Mount / Interact
activate UIApp
UIApp->>HoloClient: Connect via AppWebsocket.connect()
activate HoloClient
HoloClient-->>UIApp: Client instance stored (holochainClient.value)
deactivate HoloClient
UIApp->>UIApp: watch(holochainClient, callback)
note over UIApp: Stores register signal handlers & load initial state
User->>UIApp: Trigger action (e.g., distribute key)
UIApp->>ZomeCall: client.callZome(request)
activate ZomeCall
ZomeCall->>DHT: Commit entry + emit signal
activate DHT
DHT-->>ZomeCall: Action hash
deactivate DHT
ZomeCall-->>UIApp: Response
deactivate ZomeCall
ZomeCall->>UIApp: Emit signal (via AppWebsocket)
UIApp->>UIApp: Signal handler updates store state
UIApp->>User: UI reflects new state
deactivate UIApp
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
flake.nix (1)
93-111:⚠️ Potential issue | 🟠 Major
hc-launchremoval breaksstart:tauriandlaunch:taurinpm scripts.
package.jsonstill defineslaunch:tauriandstart:tauriscripts that invokehc launch --piped, buthc-launchhas been removed from the devShell. Runningnpm run start:tauriinsidenix developwill fail when reaching thehc launchstep.Either restore
hc-launchto the devShell packages (line 98 in flake.nix), or update/remove these scripts to usehc-spininstead (as suggested by thelaunch:happscript which already useshc-spin).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@flake.nix` around lines 93 - 111, The devShell removed hc-launch but package.json still calls it from the npm scripts start:tauri and launch:tauri; either restore hc-launch into the devShell packages list (add hc-launch to the packages array in the devShells.default block) or update the npm scripts start:tauri and launch:tauri to invoke hc-spin --piped (matching launch:happ) so the commands available in nix develop match what's referenced by the scripts; reference the hc-launch and hc-spin symbols and the start:tauri/launch:tauri script names when making the change.ui/src/checked/signing_keys/CreateKeyCollection.vue (1)
15-41:⚠️ Potential issue | 🟠 Major
callZomeis not awaited inside this async handler.Although
createKeyCollectionisasync, line 21 firesclient.value.callZome(...)withoutawait. Consequences:
- Any rejection becomes an unhandled promise rejection and never reaches
catch (e: unknown)— the just-tightened error-handling block can never be triggered for backend failures.emit("created", keyCollectionName.value)and the input-clear run synchronously, so the parent treats creation as successful even on failure.finally { creating.value = false }resets state before the call is actually done, allowing rapid duplicate submissions.🛠️ Suggested fix
try { - client.value.callZome({ + await client.value.callZome({ role_name: "checked", zome_name: "signing_keys", fn_name: "create_key_collection", payload: { name: keyCollectionName.value, }, }); emit("created", keyCollectionName.value); keyCollectionName.value = ""; } catch (e: unknown) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ui/src/checked/signing_keys/CreateKeyCollection.vue` around lines 15 - 41, The handler createKeyCollection calls client.value.callZome without awaiting it, causing unhandled rejections and premature state/reset; change it to await the callZome call (await client.value.callZome(...)) inside the try block, only emit("created", keyCollectionName.value) and clear keyCollectionName.value after the await succeeds, and let the catch(e) handle rejections so creating.value is only reset in finally after the awaited call completes; reference createKeyCollection, client.value.callZome, emit, keyCollectionName, and creating.value when making these changes.ui/src/checked/signing_keys/AddKeyToCollection.vue (1)
59-96:⚠️ Potential issue | 🟠 MajorAsync zome call is not awaited; bare block on lines 93–95 looks like a stray
finally.
client.value.callZome(...)returns a Promise but the function is synchronous, so:
- Rejections from the zome call will become unhandled promise rejections and will not reach the
catch (e: unknown)block — the error toast will never fire on backend failure.- The success notification,
emit("added"), andkeyCollectionsStore.addKeyToCollection(...)all run before the zome call has actually completed, so the UI claims success even when the call later fails.- The trailing
{ linking.value = false; }is a bare block, not afinallyclause. It currently runs because nothing throws synchronously, but the intent was clearlyfinally { ... }and the current shape will silently misbehave if anyone later adds areturnorthrowinsidetry.Recommend making the handler
async, awaiting the zome call, and using a realfinally:🛠️ Proposed fix
-const addKeyToCollection = () => { +const addKeyToCollection = async () => { if (!selectedCollection.value || !client.value || linking.value) return; linking.value = true; try { - client.value.callZome({ + await client.value.callZome({ role_name: "checked", zome_name: "signing_keys", fn_name: "link_verification_key_to_key_collection", payload: { verification_key_dist_address: props.selectedKey.key_dist_address, key_collection_name: selectedCollection.value, }, }); keyCollectionsStore.addKeyToCollection( selectedCollection.value, props.selectedKey, ); emit("added"); notificationsStore.pushNotification({ message: `Key added to collection '${selectedCollection.value}'`, type: "info", }); } catch (e: unknown) { notificationsStore.pushNotification({ message: `Error adding key to collection - ${e}`, type: "error", timeout: 5000, }); - } - { - linking.value = false; - } + } finally { + linking.value = false; + } };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ui/src/checked/signing_keys/AddKeyToCollection.vue` around lines 59 - 96, The addKeyToCollection handler currently calls client.value.callZome() without awaiting it and uses a stray bare block to reset linking.value; convert addKeyToCollection to an async function, await client.value.callZome(...) so the try/catch can catch rejections, move keyCollectionsStore.addKeyToCollection(...), emit("added"), and the success notification to run after the awaited call, and replace the trailing bare block with a proper finally { linking.value = false; } so linking is always reset even on throw; keep the same role/zome/fn payload and preserve the error notification in the catch.ui/src/checked/signing_keys/DistributeSigningKey.vue (1)
154-158:⚠️ Potential issue | 🟡 MinorMinor: duplicated word in user-facing error message.
The notification reads "Failed to distribute the verification key key: …" — the trailing "key" is duplicated.
📝 Suggested fix
- message: `Failed to distribute the verification key key: ${e}`, + message: `Failed to distribute the verification key: ${e}`,🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ui/src/checked/signing_keys/DistributeSigningKey.vue` around lines 154 - 158, The error notification message in the catch block for the distribution flow duplicates the word "key"; update the notifications.pushNotification call in DistributeSigningKey.vue (the catch handling that currently sets message: `Failed to distribute the verification key key: ${e}`) to remove the extra "key" so it reads e.g. `Failed to distribute the verification key: ${e}` while keeping the existing error interpolation and type:"error".
🧹 Nitpick comments (13)
dnas/checked/zomes/integrity/fetch/src/asset_signature.rs (1)
1-5: Optional: avoid importing this crate's ownpreludefrom an internal module.
make_asset_url_addressis defined incrate::common; re-exporting it throughpreludeand then importing it back viacrate::prelude::make_asset_url_addressfrom an internal sibling module adds an indirection. Internal modules typically use the canonical path (crate::common::make_asset_url_address), reserving thepreludefor downstream consumers. Functionally equivalent — feel free to ignore.♻️ Proposed change
use super::UnitEntryTypes; use crate::LinkTypes; -use crate::prelude::make_asset_url_address; +use crate::common::make_asset_url_address; use fetch_types::AssetSignature; use hdi::prelude::*;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@dnas/checked/zomes/integrity/fetch/src/asset_signature.rs` around lines 1 - 5, The import uses crate::prelude::make_asset_url_address from an internal sibling module; change it to import the canonical path crate::common::make_asset_url_address instead to avoid indirection. Locate the use of make_asset_url_address in this module (asset_signature.rs) and replace the prelude import with the direct crate::common::make_asset_url_address import while keeping other imports (UnitEntryTypes, LinkTypes, AssetSignature, hdi::prelude) unchanged..github/workflows/test.yaml (1)
78-78: Pinned to the latest release candidate (0.6.1-rc.8).Matches the PR objective of upgrading to 0.6.1. Consider tracking a follow-up to update to the GA
0.6.1release once it's published, to avoid keeping CI on a pre-release tag indefinitely.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/test.yaml at line 78, The workflow currently pins holochain_cli to the release candidate string "[email protected]"; update this to the GA release when it's published by replacing the package spec with "[email protected]" (remove the "-rc.8" suffix) and re-run CI to ensure the change installs cleanly, and add a short TODO or create a follow-up ticket referencing this pin so we remember to switch to the GA version if it's not already available.checked_cli/Cargo.toml (1)
39-46: Track removal of these RC-version pins once upstream stabilizes.The comment captures the iroh-relay/ed25519-dalek/curve25519-dalek/digest mismatch nicely. Two follow-ups worth filing so this doesn't silently linger:
- Once
holochain0.6.1 leaves RC and updates its transitiveiroh-relay/pkarrchain to adigestcrate that no longer relies on the removedcrypto_commonalias, these=pins (sha1,sha2,digest) should be removed — pre-release pins won't be picked up bycargo updateand will mask future security advisories on the stable lines.- Because these are pinned with
=, any other workspace member that needs a newersha1/sha2/digestwill fail to resolve. Worth verifying no other crate in the repo is on a different version line.Want me to open a tracking issue for removing the RC pins once HC 0.6.1 is stable?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@checked_cli/Cargo.toml` around lines 39 - 46, Add a short tracking task and follow-up checklist to remove the RC-version exact pins for sha1, sha2, and digest in Cargo.toml once upstream holochain/iroh-relay (and transitive ed25519-dalek/curve25519-dalek) are updated; specifically create an issue that references the exact pinned symbols (sha1, sha2, digest) and the Cargo.toml change, include steps to (a) wait for holochain 0.6.1 stable and confirm iroh-relay/ pkarr no longer require digest::crypto_common, (b) remove the "=" exact-version pins for sha1/sha2/digest, (c) run cargo update and cargo metadata to ensure no other workspace member pins or conflicts remain, and (d) verify security advisory pickup works after unpinning.ui/src/holochain-client.ts (1)
1-4: Clean module-level holder; consider whether a Pinia store would fit better.The shared
Ref<AppClient | null>is a reasonable replacement for the oldprovide/injectpattern. Consumers correctly guard viawatch(holochainClient, (client) => { if (!client) return; ... }), and the assignment in App.vue's onMounted hook does not race against consumer reads.Optional consideration: since this codebase has standardized on Pinia 3, exposing the client through a tiny Pinia store (e.g.,
useHolochainClientStore) would give you devtools visibility, easier mocking in tests, and a natural place to colocate connect/disconnect lifecycle and any future reconnect/auth-refresh logic. Not blocking — the current shape is fine for an SPA.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ui/src/holochain-client.ts` around lines 1 - 4, The module exports a module-level ref holochainClient storing AppClient|null which works but would be better surfaced via a small Pinia store for devtools, testing, and lifecycle cohesion; create a Pinia store (e.g., useHolochainClientStore) that exposes the same state currently held by holochainClient plus actions for connect/disconnect (used by App.vue onMounted to assign the client) so consumers import the store and access the client via store.client or subscribe to changes instead of the raw holochainClient ref, and move any connect/disconnect/reconnect/auth-refresh logic into that store for future maintenance and mocking.ui/src/style.css (1)
6-8: Prefer the canonical@plugin "daisyui"form.DaisyUI v5's documented Tailwind v4 integration uses
@plugin "daisyui"rather than the file pathdaisyui/index.js. The current form works, but the canonical form aligns with official documentation and is more resilient to upstream packaging changes.♻️ Suggested change
-@plugin "daisyui/index.js" { +@plugin "daisyui" { themes: bumblebee --default, luxury --prefersdark; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ui/src/style.css` around lines 6 - 8, Replace the non-canonical plugin specification `@plugin` "daisyui/index.js" with the canonical `@plugin` "daisyui" form in the CSS block that defines themes (the `@plugin` declaration around the themes: bumblebee --default, luxury --prefersdark;). Keep the themes content unchanged and only update the plugin identifier to "daisyui" so it matches DaisyUI v5/Tailwind v4 documentation and is resilient to packaging path changes.ui/src/store/key-collections-store.ts (1)
48-59: Optional: align floating-promise style withmy-keys-store.ts.
loadKeyCollectionsalready handles its own errors in atry/catch/finally, so this is purely cosmetic, but the siblingmy-keys-store.tsattaches an explicit.catch((e) => console.error(...))to the load call. Mirroring that here (and inmy-asset-signatures-store.ts) would keep the three stores consistent and silence@typescript-eslint/no-floating-promisesif it ever gets enabled.♻️ Suggested tweak
- loadKeyCollections(client); + loadKeyCollections(client).catch((e) => { + console.error("Error loading key collections", e); + });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ui/src/store/key-collections-store.ts` around lines 48 - 59, The watch callback invokes loadKeyCollections(client) but leaves the returned promise unhandled; change the call in the watch callback inside key-collections-store.ts to append a .catch(...) that logs the error (mirroring my-keys-store.ts) so the promise is not floating and ESLint won’t complain; update the same pattern in my-asset-signatures-store.ts as well, keeping the existing try/catch inside loadKeyCollections and only adding the .catch on the external invocation (reference: watch(..., (client) => { ... registerSignalHandler(..., { keyCollectionsStore: { pushKeyCollection } }); loadKeyCollections(client) }) and the pushKeyCollection registration).Cargo.toml (1)
14-32: LGTM — workspace deps line up with downstream crate manifests and call-site usage.A few cross-checks:
rand0.10.1 with thethread_rngfeature enablesrand::rng(), which is exactly whatasset_signature.rsuses;holochain_serialized_bytes = "0.0.57"matches theSerializedBytesderives intypes/signing_keys; and excludingtestsfrom the workspace is correct now that it's the sweettest crate with a heavier holochain dep tree.Optional: the HC core crates are pinned with
=0.6.1-rc.5whileholochain_zome_types/holo_hashuse a non-=constraint — minor inconsistency that could let cargo pick a different rc minor if one ships before the final 0.6.1 release. Consider=on all four for fully reproducible builds until 0.6.1 stabilizes.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Cargo.toml` around lines 14 - 32, The workspace dependency pins are inconsistent: hdi and hdk use exact (=0.7.1-rc.5 and =0.6.1-rc.5) but holochain_zome_types and holo_hash use loose constraints; update the entries for holochain_zome_types and holo_hash in the workspace.dependencies to use the same exact-version („=0.6.1-rc.5“) format as hdk/hdi so Cargo cannot accidentally pick a different rc minor — adjust the version strings for holochain_zome_types and holo_hash to include the leading '=' to match the other HC core crates.tests/src/lib.rs (2)
345-372: Consider promoting these request types to a shared*_typescrate.The local mirrors (
LinkVfKeyDistToKeyCollectionRequest,UnlinkVfKeyFromKeyCollectionRequest,SearchKeysRequest,MarkVfKeyDistRequest) are intentional copies of structs declared inside coordinator zomes. This works (sweettest'scall_fallibleonly needsSerialize), but any future field rename/addition in the coordinator's struct will silently desync this mirror — the call will succeed but deserialize to default/unexpected values on the zome side. Long term, exposing these viatypes/signing_keys/(similar to howDistributeVfKeyRequestalready lives there) avoids the drift class entirely.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/src/lib.rs` around lines 345 - 372, The four local mirror structs (LinkVfKeyDistToKeyCollectionRequest, UnlinkVfKeyFromKeyCollectionRequest, SearchKeysRequest, MarkVfKeyDistRequest) should be moved into the shared types crate (e.g., types::signing_keys) and re-exported so both the coordinator zomes and tests import the canonical definitions; remove the duplicated local declarations in tests/src/lib.rs, add use imports from the shared crate where these types are referenced (matching the existing DistributeVfKeyRequest pattern), and run cargo to ensure serialization traits (Serialize/Deserialize) and any dependent enums like MarkVfKeyDistOpt/AgentPubKey/ActionHash are properly exported or re-exported from the types crate.
100-129: Retry helper uses fixed-delay; consider exponential backoff.
with_retrypolls every 500 ms for up to 10 attempts (~5 s total). For the in-process sweettest network, a fixed cadence is usually fine, but for themust_get_agent_activitycascade path this is sometimes too short, which is partially why several call sites are still#[ignore]d. Switching to exponential backoff (e.g., 250 ms → ~10 s budget) would absorb more of the cascade-warming variance without ballooning best-case latency. Optional.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/src/lib.rs` around lines 100 - 129, Update the with_retry helper to use exponential backoff instead of a fixed 500ms delay: replace the DELAY_MS constant with an initial_delay_ms (e.g., 250) and on each retry compute sleep_duration = initial_delay_ms * 2u64.pow(attempt_index) (optionally cap with a max_delay_ms to avoid unbounded waits), then call tokio::time::sleep(Duration::from_millis(sleep_duration)). Keep the same MAX_ATTEMPTS, preserve the error handling and last_err logic in with_retry, and ensure you use the loop index to compute the backoff for the tokio::time::sleep call.dnas/checked/zomes/coordinator/fetch/src/asset_signature.rs (1)
436-436: Unusual&mut rand::rng()binding — verify intent.
let mut rng = &mut rand::rng();bindsrngto a&mut ThreadRngover a temporary. This compiles because rust extends the temporary's lifetime, andrand::seq::IndexedRandomexamples in the rand 0.9 docs use this same form. So calls likeshuffle(&mut rng)(passing&mut &mut R) are accepted via the blanketRng for &mut Rimpl. No correctness bug, but the simplerlet mut rng = rand::rng();is more idiomatic. Optional cleanup.Also applies to: 529-529, 589-589
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@dnas/checked/zomes/coordinator/fetch/src/asset_signature.rs` at line 436, The current binding let mut rng = &mut rand::rng(); creates a mutable reference to a temporary and is non-idiomatic; change it to let mut rng = rand::rng(); in the places noted (the rng variable at the three occurrences) so subsequent uses (e.g., calls that pass &mut rng such as shuffle/sample_slice/choose) continue to work via the &mut R impl but without binding to a temporary reference. Update each occurrence (the declarations of rng at the three highlighted lines) accordingly.tests/Cargo.toml (1)
18-25: Document-only: track removal of the digest/sha1/sha2 RC pins.Pinning to RC versions of
sha1/sha2/digestwith=is a reasonable short-term workaround, but it will silently block any patch fixes (including security fixes) that land on those RC streams and bumping Holochain past the rc.8 dev-dep chain may flip the resolver back to adigest 0.11.xthat no longer needs this pin. Consider opening a tracking issue/TODO so these pins get revisited when the upstream chain updates iroh-relay/ed25519-dalek/curve25519-dalek to a stable digest 0.11+.Want me to draft a short tracking issue referencing the upstream curve25519-dalek/ed25519-dalek pre-releases that this pin is gating on?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/Cargo.toml` around lines 18 - 25, Update this document-only workaround by adding a short tracking TODO and creating a repository issue so the RC pins for sha1/sha2/digest (the entries "sha1", "sha2", and "digest" in Cargo.toml) are revisited when upstream stabilizes; modify the existing comment block to reference that tracking issue and to note the exact upstream pre-releases (curve25519-dalek/ed25519-dalek) that this pin is gating on, and open the issue with a brief description and links to those upstream pre-releases so maintainers can remove the "=" RC pins once upstream updates.tests/tests/fetch.rs (1)
271-298: Index-based reason assertions assumepick_signaturesordering stays stable.
check_signatures_alice[0].reason == Mine/[1] == RandomRecent(and the same shape for bob) rely on the implicit category order produced bypick_signatures. That's currentlyMine → Pinned → Historical → Recent, but an implementation tweak that reorders categories or stably sorts results would silently break these without indicating a real regression. Consider asserting viaiter().any(|r| r.reason == ...)or matching the multiset of reasons.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/tests/fetch.rs` around lines 271 - 298, The tests currently assert fixed positions for FetchCheckSignatureReason values produced by prepare_fetch and pick_signatures (e.g., check_signatures_alice[0].reason == Mine), which is fragile to category reordering; update the assertions to check for presence rather than index: for each of check_signatures_alice and check_signatures_bob, collect or iterate the reasons (or the (author,reason) pairs) and assert the expected reasons exist (use iter().any(|r| r.reason == FetchCheckSignatureReason::Mine), iter().any(...RandomRecent), or compare multisets of reasons), and for bob keep the pinned-specific checks by finding the entry whose reason matches FetchCheckSignatureReason::Pinned and then assert its pinned.key_name/key_collection and author match expectations. Ensure you reference prepare_fetch, pick_signatures, check_signatures_alice, check_signatures_bob, and FetchCheckSignatureReason when locating code to change.tests/tests/signing_keys.rs (1)
174-177: Brittle substring match on error message.
err.to_string().contains("maximum")is fine as a smoke check, but tightly couples this test to the exact error text increate_key_collection. Consider matching a more specific phrase (or asserting on a typed error) so harmless wording tweaks in the zome don't silently turn this from a real-failure assertion into a no-op.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/tests/signing_keys.rs` around lines 174 - 177, The test currently does a brittle substring check on the error string from create_key_collection (err.to_string().contains("maximum")); instead, assert a specific error type or a more precise phrase: capture err from create_key_collection(&conductor, &alice, "a test too many").await.unwrap_err() and either pattern-match the error to the concrete variant (e.g. match/assert that err.downcast_ref::<SigningError>() == Some(&SigningError::TooManyKeyCollections) or use assert_matches! on the returned Err), or at minimum check a tighter message fragment like "too many key collections" rather than the generic "maximum" to avoid fragile wording changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yaml:
- Around line 26-29: The cachix step using cachix/cachix-action@v17 in the
release workflow is missing the authToken so it cannot push artifacts to the
esl-checked cache; update the step for the release job (the cachix action block)
to include authToken: ${{ secrets.CACHIX_AUTH_TOKEN }} so release builds can
push, or if intentional, add a brief comment above the cachix step explaining
why writes are disabled for releases; target the cachix action block (uses:
cachix/cachix-action@v17 / with: name: esl-checked) when making this change.
In `@dnas/checked/zomes/coordinator/fetch/Cargo.toml`:
- Line 12: Remove the unused dependency entry holochain_serialized_bytes from
the crate's Cargo.toml (the dependency line "holochain_serialized_bytes = {
workspace = true }"); there are no references to that crate in the source and
hdk already re-exports the needed serialization types/traits, so delete that
dependency line to avoid an unnecessary dependency.
In `@dnas/checked/zomes/coordinator/fetch/src/asset_signature.rs`:
- Around line 306-309: Fix the typo in the warn! message inside
asset_signature.rs where the string currently reads "asset signature signature";
update the warn! call (referencing sig.key_dist_address and the warn! invocation
in the same block) to remove the duplicated "signature" so it reads e.g.
"Discarding my existing asset signature because the key distribution could not
be fetched: {:?}" while keeping the sig.key_dist_address interpolation
unchanged.
In `@types/checked_types/Cargo.toml`:
- Line 8: Remove the unused holochain_serialized_bytes dependency from
Cargo.toml by deleting the line "holochain_serialized_bytes = { workspace = true
}"; then run cargo check/build to verify no remaining references to
SerializedBytes. Also scan the crate for any leftover use/imports or types named
SerializedBytes and remove them if present, ensuring only holochain_zome_types
and serde are imported and used.
---
Outside diff comments:
In `@flake.nix`:
- Around line 93-111: The devShell removed hc-launch but package.json still
calls it from the npm scripts start:tauri and launch:tauri; either restore
hc-launch into the devShell packages list (add hc-launch to the packages array
in the devShells.default block) or update the npm scripts start:tauri and
launch:tauri to invoke hc-spin --piped (matching launch:happ) so the commands
available in nix develop match what's referenced by the scripts; reference the
hc-launch and hc-spin symbols and the start:tauri/launch:tauri script names when
making the change.
In `@ui/src/checked/signing_keys/AddKeyToCollection.vue`:
- Around line 59-96: The addKeyToCollection handler currently calls
client.value.callZome() without awaiting it and uses a stray bare block to reset
linking.value; convert addKeyToCollection to an async function, await
client.value.callZome(...) so the try/catch can catch rejections, move
keyCollectionsStore.addKeyToCollection(...), emit("added"), and the success
notification to run after the awaited call, and replace the trailing bare block
with a proper finally { linking.value = false; } so linking is always reset even
on throw; keep the same role/zome/fn payload and preserve the error notification
in the catch.
In `@ui/src/checked/signing_keys/CreateKeyCollection.vue`:
- Around line 15-41: The handler createKeyCollection calls client.value.callZome
without awaiting it, causing unhandled rejections and premature state/reset;
change it to await the callZome call (await client.value.callZome(...)) inside
the try block, only emit("created", keyCollectionName.value) and clear
keyCollectionName.value after the await succeeds, and let the catch(e) handle
rejections so creating.value is only reset in finally after the awaited call
completes; reference createKeyCollection, client.value.callZome, emit,
keyCollectionName, and creating.value when making these changes.
In `@ui/src/checked/signing_keys/DistributeSigningKey.vue`:
- Around line 154-158: The error notification message in the catch block for the
distribution flow duplicates the word "key"; update the
notifications.pushNotification call in DistributeSigningKey.vue (the catch
handling that currently sets message: `Failed to distribute the verification key
key: ${e}`) to remove the extra "key" so it reads e.g. `Failed to distribute the
verification key: ${e}` while keeping the existing error interpolation and
type:"error".
---
Nitpick comments:
In @.github/workflows/test.yaml:
- Line 78: The workflow currently pins holochain_cli to the release candidate
string "[email protected]"; update this to the GA release when it's
published by replacing the package spec with "[email protected]" (remove the
"-rc.8" suffix) and re-run CI to ensure the change installs cleanly, and add a
short TODO or create a follow-up ticket referencing this pin so we remember to
switch to the GA version if it's not already available.
In `@Cargo.toml`:
- Around line 14-32: The workspace dependency pins are inconsistent: hdi and hdk
use exact (=0.7.1-rc.5 and =0.6.1-rc.5) but holochain_zome_types and holo_hash
use loose constraints; update the entries for holochain_zome_types and holo_hash
in the workspace.dependencies to use the same exact-version („=0.6.1-rc.5“)
format as hdk/hdi so Cargo cannot accidentally pick a different rc minor —
adjust the version strings for holochain_zome_types and holo_hash to include the
leading '=' to match the other HC core crates.
In `@checked_cli/Cargo.toml`:
- Around line 39-46: Add a short tracking task and follow-up checklist to remove
the RC-version exact pins for sha1, sha2, and digest in Cargo.toml once upstream
holochain/iroh-relay (and transitive ed25519-dalek/curve25519-dalek) are
updated; specifically create an issue that references the exact pinned symbols
(sha1, sha2, digest) and the Cargo.toml change, include steps to (a) wait for
holochain 0.6.1 stable and confirm iroh-relay/ pkarr no longer require
digest::crypto_common, (b) remove the "=" exact-version pins for
sha1/sha2/digest, (c) run cargo update and cargo metadata to ensure no other
workspace member pins or conflicts remain, and (d) verify security advisory
pickup works after unpinning.
In `@dnas/checked/zomes/coordinator/fetch/src/asset_signature.rs`:
- Line 436: The current binding let mut rng = &mut rand::rng(); creates a
mutable reference to a temporary and is non-idiomatic; change it to let mut rng
= rand::rng(); in the places noted (the rng variable at the three occurrences)
so subsequent uses (e.g., calls that pass &mut rng such as
shuffle/sample_slice/choose) continue to work via the &mut R impl but without
binding to a temporary reference. Update each occurrence (the declarations of
rng at the three highlighted lines) accordingly.
In `@dnas/checked/zomes/integrity/fetch/src/asset_signature.rs`:
- Around line 1-5: The import uses crate::prelude::make_asset_url_address from
an internal sibling module; change it to import the canonical path
crate::common::make_asset_url_address instead to avoid indirection. Locate the
use of make_asset_url_address in this module (asset_signature.rs) and replace
the prelude import with the direct crate::common::make_asset_url_address import
while keeping other imports (UnitEntryTypes, LinkTypes, AssetSignature,
hdi::prelude) unchanged.
In `@tests/Cargo.toml`:
- Around line 18-25: Update this document-only workaround by adding a short
tracking TODO and creating a repository issue so the RC pins for
sha1/sha2/digest (the entries "sha1", "sha2", and "digest" in Cargo.toml) are
revisited when upstream stabilizes; modify the existing comment block to
reference that tracking issue and to note the exact upstream pre-releases
(curve25519-dalek/ed25519-dalek) that this pin is gating on, and open the issue
with a brief description and links to those upstream pre-releases so maintainers
can remove the "=" RC pins once upstream updates.
In `@tests/src/lib.rs`:
- Around line 345-372: The four local mirror structs
(LinkVfKeyDistToKeyCollectionRequest, UnlinkVfKeyFromKeyCollectionRequest,
SearchKeysRequest, MarkVfKeyDistRequest) should be moved into the shared types
crate (e.g., types::signing_keys) and re-exported so both the coordinator zomes
and tests import the canonical definitions; remove the duplicated local
declarations in tests/src/lib.rs, add use imports from the shared crate where
these types are referenced (matching the existing DistributeVfKeyRequest
pattern), and run cargo to ensure serialization traits (Serialize/Deserialize)
and any dependent enums like MarkVfKeyDistOpt/AgentPubKey/ActionHash are
properly exported or re-exported from the types crate.
- Around line 100-129: Update the with_retry helper to use exponential backoff
instead of a fixed 500ms delay: replace the DELAY_MS constant with an
initial_delay_ms (e.g., 250) and on each retry compute sleep_duration =
initial_delay_ms * 2u64.pow(attempt_index) (optionally cap with a max_delay_ms
to avoid unbounded waits), then call
tokio::time::sleep(Duration::from_millis(sleep_duration)). Keep the same
MAX_ATTEMPTS, preserve the error handling and last_err logic in with_retry, and
ensure you use the loop index to compute the backoff for the tokio::time::sleep
call.
In `@tests/tests/fetch.rs`:
- Around line 271-298: The tests currently assert fixed positions for
FetchCheckSignatureReason values produced by prepare_fetch and pick_signatures
(e.g., check_signatures_alice[0].reason == Mine), which is fragile to category
reordering; update the assertions to check for presence rather than index: for
each of check_signatures_alice and check_signatures_bob, collect or iterate the
reasons (or the (author,reason) pairs) and assert the expected reasons exist
(use iter().any(|r| r.reason == FetchCheckSignatureReason::Mine),
iter().any(...RandomRecent), or compare multisets of reasons), and for bob keep
the pinned-specific checks by finding the entry whose reason matches
FetchCheckSignatureReason::Pinned and then assert its
pinned.key_name/key_collection and author match expectations. Ensure you
reference prepare_fetch, pick_signatures, check_signatures_alice,
check_signatures_bob, and FetchCheckSignatureReason when locating code to
change.
In `@tests/tests/signing_keys.rs`:
- Around line 174-177: The test currently does a brittle substring check on the
error string from create_key_collection (err.to_string().contains("maximum"));
instead, assert a specific error type or a more precise phrase: capture err from
create_key_collection(&conductor, &alice, "a test too many").await.unwrap_err()
and either pattern-match the error to the concrete variant (e.g. match/assert
that err.downcast_ref::<SigningError>() ==
Some(&SigningError::TooManyKeyCollections) or use assert_matches! on the
returned Err), or at minimum check a tighter message fragment like "too many key
collections" rather than the generic "maximum" to avoid fragile wording changes.
In `@ui/src/holochain-client.ts`:
- Around line 1-4: The module exports a module-level ref holochainClient storing
AppClient|null which works but would be better surfaced via a small Pinia store
for devtools, testing, and lifecycle cohesion; create a Pinia store (e.g.,
useHolochainClientStore) that exposes the same state currently held by
holochainClient plus actions for connect/disconnect (used by App.vue onMounted
to assign the client) so consumers import the store and access the client via
store.client or subscribe to changes instead of the raw holochainClient ref, and
move any connect/disconnect/reconnect/auth-refresh logic into that store for
future maintenance and mocking.
In `@ui/src/store/key-collections-store.ts`:
- Around line 48-59: The watch callback invokes loadKeyCollections(client) but
leaves the returned promise unhandled; change the call in the watch callback
inside key-collections-store.ts to append a .catch(...) that logs the error
(mirroring my-keys-store.ts) so the promise is not floating and ESLint won’t
complain; update the same pattern in my-asset-signatures-store.ts as well,
keeping the existing try/catch inside loadKeyCollections and only adding the
.catch on the external invocation (reference: watch(..., (client) => { ...
registerSignalHandler(..., { keyCollectionsStore: { pushKeyCollection } });
loadKeyCollections(client) }) and the pushKeyCollection registration).
In `@ui/src/style.css`:
- Around line 6-8: Replace the non-canonical plugin specification `@plugin`
"daisyui/index.js" with the canonical `@plugin` "daisyui" form in the CSS block
that defines themes (the `@plugin` declaration around the themes: bumblebee
--default, luxury --prefersdark;). Keep the themes content unchanged and only
update the plugin identifier to "daisyui" so it matches DaisyUI v5/Tailwind v4
documentation and is resilient to packaging path changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 496165e0-7e8e-4b61-a1d0-d90683c9664e
⛔ Files ignored due to path filters (5)
Cargo.lockis excluded by!**/*.lockchecked_cli/Cargo.lockis excluded by!**/*.lockflake.lockis excluded by!**/*.lockpackage-lock.jsonis excluded by!**/package-lock.jsontests/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (69)
.github/workflows/flake_update.yaml.github/workflows/release.yaml.github/workflows/test.yaml.gitignoreCargo.tomlchecked_cli/Cargo.tomlchecked_cli/src/distribute.rschecked_cli/src/fetch.rschecked_cli/src/hc_client.rschecked_cli/src/hc_discover.rschecked_cli/src/lib.rschecked_cli/src/sign.rschecked_cli/tests/commands.rschecked_cli/tests/happ_integration.rsdnas/checked/workdir/dna.yamldnas/checked/zomes/coordinator/fetch/Cargo.tomldnas/checked/zomes/coordinator/fetch/src/asset_signature.rsdnas/checked/zomes/coordinator/fetch/src/lib.rsdnas/checked/zomes/coordinator/signing_keys/Cargo.tomldnas/checked/zomes/coordinator/signing_keys/src/key_collection.rsdnas/checked/zomes/coordinator/signing_keys/src/lib.rsdnas/checked/zomes/coordinator/signing_keys/src/verification_key_dist.rsdnas/checked/zomes/integrity/fetch/Cargo.tomldnas/checked/zomes/integrity/fetch/src/asset_signature.rsdnas/checked/zomes/integrity/fetch/src/lib.rsdnas/checked/zomes/integrity/signing_keys/Cargo.tomldnas/checked/zomes/integrity/signing_keys/src/key_collection.rsdnas/checked/zomes/integrity/signing_keys/src/lib.rsflake.nixpackage.jsonrust-toolchain.tomltests/Cargo.tomltests/eslint.config.jstests/package.jsontests/src/checked/common.tstests/src/checked/fetch/common.tstests/src/checked/fetch/fetch.test.tstests/src/checked/signing_keys/common.tstests/src/checked/signing_keys/key-collection.test.tstests/src/checked/signing_keys/reference-count.test.tstests/src/checked/signing_keys/validation-key-dist.test.tstests/src/lib.rstests/tests/fetch.rstests/tests/signing_keys.rstests/vitest.config.tstypes/checked_types/Cargo.tomltypes/fetch/Cargo.tomltypes/signing_keys/Cargo.tomlui/.eslintrc.cjsui/eslint.config.mjsui/package.jsonui/postcss.config.jsui/src/App.vueui/src/checked/signing_keys/AddKeyToCollection.vueui/src/checked/signing_keys/CreateKeyCollection.vueui/src/checked/signing_keys/DistributeSigningKey.vueui/src/checked/signing_keys/SearchKeys.vueui/src/holochain-client.tsui/src/signals.tsui/src/store/key-collections-store.tsui/src/store/my-asset-signatures-store.tsui/src/store/my-keys-store.tsui/src/style.cssui/tailwind.config.jsui/tsconfig.jsonui/tsconfig.node.jsonui/vite.config.tsworkdir/happ.yamlworkdir/web-happ.yaml
💤 Files with no reviewable changes (13)
- ui/.eslintrc.cjs
- tests/src/checked/signing_keys/key-collection.test.ts
- tests/src/checked/signing_keys/reference-count.test.ts
- tests/package.json
- tests/src/checked/signing_keys/validation-key-dist.test.ts
- tests/src/checked/fetch/fetch.test.ts
- tests/vitest.config.ts
- tests/src/checked/common.ts
- tests/src/checked/fetch/common.ts
- tests/eslint.config.js
- ui/postcss.config.js
- ui/tailwind.config.js
- tests/src/checked/signing_keys/common.ts
Comment on lines
+26
to
29
| - uses: cachix/cachix-action@v17 | ||
| with: | ||
| name: esl-checked | ||
| extraPullNames: holochain-ci |
There was a problem hiding this comment.
Missing authToken for cachix/cachix-action@v17 — release builds will not push to the binary cache.
Compared to .github/workflows/test.yaml (lines 26-29 in the relevant snippet) which passes authToken: ${{ secrets.CACHIX_AUTH_TOKEN }}, this release job omits it. Without an auth token, cachix is read-only: derivations built during release won't be pushed to esl-checked, so subsequent CI/dev environments lose the caching benefit of the release build. If this is intentional (e.g., release should not write to cache), a brief comment would help; otherwise add the token.
🔧 Proposed fix
- uses: cachix/cachix-action@v17
with:
name: esl-checked
extraPullNames: holochain-ci
+ authToken: ${{ secrets.CACHIX_AUTH_TOKEN }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - uses: cachix/cachix-action@v17 | |
| with: | |
| name: esl-checked | |
| extraPullNames: holochain-ci | |
| - uses: cachix/cachix-action@v17 | |
| with: | |
| name: esl-checked | |
| extraPullNames: holochain-ci | |
| authToken: ${{ secrets.CACHIX_AUTH_TOKEN }} |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yaml around lines 26 - 29, The cachix step using
cachix/cachix-action@v17 in the release workflow is missing the authToken so it
cannot push artifacts to the esl-checked cache; update the step for the release
job (the cachix action block) to include authToken: ${{
secrets.CACHIX_AUTH_TOKEN }} so release builds can push, or if intentional, add
a brief comment above the cachix step explaining why writes are disabled for
releases; target the cachix action block (uses: cachix/cachix-action@v17 / with:
name: esl-checked) when making this change.
|
|
||
| [dependencies] | ||
| hdk = { workspace = true } | ||
| holochain_serialized_bytes = { workspace = true } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for any direct references to holochain_serialized_bytes in the fetch coordinator crate.
fd -t f -e rs . dnas/checked/zomes/coordinator/fetch | xargs rg -nP '\bholochain_serialized_bytes\b' || echo "No direct references found."Repository: EphyraSoftware/checked
Length of output: 94
Remove the unused holochain_serialized_bytes dependency.
No direct references to holochain_serialized_bytes exist in the crate's source. Since hdk already re-exports the serialization types and traits, this dependency is unnecessary and should be removed from line 12.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@dnas/checked/zomes/coordinator/fetch/Cargo.toml` at line 12, Remove the
unused dependency entry holochain_serialized_bytes from the crate's Cargo.toml
(the dependency line "holochain_serialized_bytes = { workspace = true }"); there
are no references to that crate in the source and hdk already re-exports the
needed serialization types/traits, so delete that dependency line to avoid an
unnecessary dependency.
Comment on lines
+306
to
+309
| warn!( | ||
| "Discarding my existing asset signature signature because the key distribution could not be fetched: {:?}", | ||
| sig.key_dist_address | ||
| ); |
There was a problem hiding this comment.
Typo in warning message: duplicated "signature".
The reflowed warn! reads "asset signature signature". Looks like a stray duplicated word.
📝 Proposed fix
warn!(
- "Discarding my existing asset signature signature because the key distribution could not be fetched: {:?}",
+ "Discarding my existing asset signature because the key distribution could not be fetched: {:?}",
sig.key_dist_address
);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| warn!( | |
| "Discarding my existing asset signature signature because the key distribution could not be fetched: {:?}", | |
| sig.key_dist_address | |
| ); | |
| warn!( | |
| "Discarding my existing asset signature because the key distribution could not be fetched: {:?}", | |
| sig.key_dist_address | |
| ); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@dnas/checked/zomes/coordinator/fetch/src/asset_signature.rs` around lines 306
- 309, Fix the typo in the warn! message inside asset_signature.rs where the
string currently reads "asset signature signature"; update the warn! call
(referencing sig.key_dist_address and the warn! invocation in the same block) to
remove the duplicated "signature" so it reads e.g. "Discarding my existing asset
signature because the key distribution could not be fetched: {:?}" while keeping
the sig.key_dist_address interpolation unchanged.
| [dependencies] | ||
| serde = { workspace = true } | ||
| holochain_zome_types = { workspace = true } | ||
| holochain_serialized_bytes = { workspace = true } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Look for direct references to holochain_serialized_bytes in the checked_types crate
fd -t f -e rs . types/checked_types/src 2>/dev/null | xargs rg -nP '\bholochain_serialized_bytes\b|\bSerializedBytes\b' || true
# Also look for derive macros that require SB to be in scope
fd -t f -e rs . types/checked_types/src 2>/dev/null | xargs rg -nP 'derive\([^)]*SerializedBytes' || trueRepository: EphyraSoftware/checked
Length of output: 48
🏁 Script executed:
# Verify the dependency actually exists in Cargo.toml
cat types/checked_types/Cargo.toml
# List all Rust files in the crate
echo "=== All Rust files in checked_types ==="
find types/checked_types/src -type f -name "*.rs"
# Search for any imports or use statements that might reference the crate indirectly
echo "=== Search for use statements and imports ==="
find types/checked_types/src -type f -name "*.rs" -exec grep -l "use\|extern" {} \;Repository: EphyraSoftware/checked
Length of output: 421
🏁 Script executed:
# Read the lib.rs file to see what's actually imported/exported
cat types/checked_types/src/lib.rsRepository: EphyraSoftware/checked
Length of output: 2204
Remove the unused holochain_serialized_bytes dependency.
The crate imports only from holochain_zome_types (for ActionHash, AgentPubKey, Timestamp) and serde. No code in the crate references holochain_serialized_bytes or SerializedBytes. This dependency adds unnecessary bloat and should be removed from Cargo.toml.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@types/checked_types/Cargo.toml` at line 8, Remove the unused
holochain_serialized_bytes dependency from Cargo.toml by deleting the line
"holochain_serialized_bytes = { workspace = true }"; then run cargo check/build
to verify no remaining references to SerializedBytes. Also scan the crate for
any leftover use/imports or types named SerializedBytes and remove them if
present, ensuring only holochain_zome_types and serde are imported and used.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Continues the Holochain 0.6.1 upgrade by retiring the deprecated tryorama JS test stack and modernizing the UI toolchain.
test:Replaces the JS tryorama integration suite with a Rust sweettest crate undertests/. 19 tests pass; 3 cross-agent delete-link tests are#[ignore]d for the same reason upstream gates its own consistency tests ontransport-iroh(the defaulttx5/go-pionbackend can't reliably delivermust_get_agent_activitydeps).chore(types):Bumpstypes/*crates to edition 2024 to match the rest of the workspace.chore(ui):Modernizes the UI dep stack — TS 6, Vite 8, ESLint 10 (flat config), Vue 3.5, vue-router 5, Pinia 3,@holochain/client0.20, Tailwind v4 + daisyui v5 (CSS-first config). Includes the source-level adaptations the new strict ruleset requires (catch (e: unknown), drop unusedSignalTypeimport) and a fix for Pinia 3's stricterrunWithContext: replaces component-scopedprovide('client', ...)/inject('client')with a module-levelRefinsrc/holochain-client.ts, since Pinia 3 setup stores can no longer see component-level provides.ci:Renames the integration test step and dropsubuntu-latestfrom thecli-testmatrix (the nixtestjob already covers it).Test plan
cargo fmt --checkclean across root,checked_cli, andtestsworkspacescargo clippy -- --deny warningsclean across all three workspacescargo testpasses for unit testsnpm run test:integration— 8 fetch + 11 signing_keys pass; 3 ignorednpm run lintandnpm run buildforuiworkspace passSummary by CodeRabbit
Release Notes
Chores
Refactor
Style