fix(kvm): declare tokio sync + fs features so the crate publishes standalone (VA-135) #144

Merged

longjacksonle merged 1 commit from fix/VA-135-kvm-tokio-features into main

2026-07-15 18:30:51 +02:00

longjacksonle commented

2026-07-15 18:16:07 +02:00

Owner

Fixes VA-135: publish-crates.yml failed to publish vervain-agent-kvm on the v0.4.0 tag (run 565) with tokio::sync unresolved (module sync is private).

Root cause

vervain-agent-kvm uses tokio APIs whose features it never declared:

tokio::sync::Notify (session_ctx.rs) and tokio::sync::Mutex (portal.rs) -> needs sync
tokio::fs::read / tokio::fs::remove_file (wayland.rs) -> needs fs

The crate declared only macros, rt, process, time. Inside the workspace this compiled anyway because vervain-agent enables the same tokio features and cargo unifies features onto shared dependencies. cargo publish builds the crate in isolation with no unification, so the undeclared features were missing and the verification build failed. The run got as far as sync (session_ctx) before erroring; fs (wayland.rs) would fail next, so both are needed. Both modules compile unconditionally on Linux, where publish-crates.yml runs.

Fix

Add sync and fs to the kvm crate's own tokio features. One-line dependency change plus a comment explaining why the crate must declare them for standalone publish.

Validation

cargo package -p vervain-agent-kvm (the publish-equivalent build: fresh target/package tree, crate-only features) now compiles clean where it previously failed. This is the exact step publish-crates.yml runs.
cargo check -p vervain-agent-kvm and cargo test -p vervain-agent-kvm --lib (93 passed) now pass standalone.
Full workspace clippy --all-targets --deny warnings unaffected (features are additive).

Republish note

The v0.4.0 kvm crate never uploaded (verification failed before publish); mcp uploaded at 0.4.0. A new tag (v0.4.1) republishes both at a matching version and reconciles the skew. Cutting the release is a separate, maintainer-driven step (just create-release hotfix), not part of this PR.

🤖 Generated with Claude Code

Fixes VA-135: publish-crates.yml failed to publish `vervain-agent-kvm` on the v0.4.0 tag (run 565) with `tokio::sync` unresolved (module `sync` is private). ## Root cause vervain-agent-kvm uses tokio APIs whose features it never declared: - `tokio::sync::Notify` (`session_ctx.rs`) and `tokio::sync::Mutex` (`portal.rs`) -> needs `sync` - `tokio::fs::read` / `tokio::fs::remove_file` (`wayland.rs`) -> needs `fs` The crate declared only `macros`, `rt`, `process`, `time`. Inside the workspace this compiled anyway because `vervain-agent` enables the same tokio features and cargo unifies features onto shared dependencies. `cargo publish` builds the crate in isolation with no unification, so the undeclared features were missing and the verification build failed. The run got as far as `sync` (session_ctx) before erroring; `fs` (wayland.rs) would fail next, so both are needed. Both modules compile unconditionally on Linux, where publish-crates.yml runs. ## Fix Add `sync` and `fs` to the kvm crate's own tokio features. One-line dependency change plus a comment explaining why the crate must declare them for standalone publish. ## Validation - `cargo package -p vervain-agent-kvm` (the publish-equivalent build: fresh `target/package` tree, crate-only features) now compiles clean where it previously failed. This is the exact step publish-crates.yml runs. - `cargo check -p vervain-agent-kvm` and `cargo test -p vervain-agent-kvm --lib` (93 passed) now pass standalone. - Full workspace `clippy --all-targets --deny warnings` unaffected (features are additive). ## Republish note The v0.4.0 kvm crate never uploaded (verification failed before publish); mcp uploaded at 0.4.0. A new tag (v0.4.1) republishes both at a matching version and reconciles the skew. Cutting the release is a separate, maintainer-driven step (`just create-release hotfix`), not part of this PR. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

longjacksonle added 1 commit

2026-07-15 18:16:08 +02:00

fix(kvm): declare tokio sync + fs features so the crate publishes standalone (VA-135)

Check / fmt + clippy + tests (pull_request) Successful in 4m15s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

69ac708fc1

vervain-agent-kvm uses `tokio::sync::{Notify, Mutex}` (session_ctx.rs, portal.rs) and `tokio::fs::{read, remove_file}` (wayland.rs) but only declared the `macros`, `rt`, `process`, and `time` tokio features. Inside the workspace this compiled because `vervain-agent` enables the same tokio features and cargo unifies them onto the kvm crate. `cargo publish` builds the crate in isolation with no such unification, so `tokio::sync` was a private module and the verification build failed. This broke publish-crates.yml on the v0.4.0 tag (run 565): vervain-agent-mcp published but vervain-agent-kvm did not.

Add `sync` and `fs` to the kvm crate's own tokio features so it builds on its own. Both `session_ctx.rs` (`sync`) and `wayland.rs` (`fs`) compile unconditionally on Linux, which is where publish-crates.yml runs, so both features are required.

Verified with the publish-equivalent isolated build, `cargo package -p vervain-agent-kvm` (fresh target/package tree, crate-only features), which now compiles clean where it previously failed; `cargo check -p vervain-agent-kvm` and `cargo test -p vervain-agent-kvm --lib` also pass standalone now, and the full workspace clippy --deny warnings is unaffected.

Republishing needs a new tag: the v0.4.0 kvm crate never uploaded (verification failed before publish), while mcp uploaded at 0.4.0. Cutting v0.4.1 republishes both at a matching version and reconciles the skew.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LYb1fkK32XQdwkGkStxXR9
Signed-off-by: longjacksonle <longjacksonle@gmail.com>