chore(deps): bump cachekit-core to 0.4.0 (LAB-902)

[27Bslash6]

Closes LAB-902 (parent LAB-764, stage 5).

Bump cachekit-core 0.3 → 0.4 in crates/cachekit/Cargo.toml + lockfile. cachekit-rs consumes core only for encryption (ZeroKnowledgeEncryptor, tenant key derivation in src/encryption.rs); values remain plain MessagePack with no ByteStorage/StorageEnvelope surface — grep confirms envelope identifiers appear only in doc comments/tests asserting their absence.

Local verification against 0.4.0 (mirrors CI):

• cargo fmt --all -- --check ✅
• cargo clippy --all-targets --features "cachekitio,redis,encryption,l1,macros,memcached,file" -- -D warnings ✅
• cargo test --features "cachekitio,redis,encryption,l1,macros,memcached,file" ✅ (all suites, incl. interop encryption round-trip vectors — byte-verified against protocol fixtures)
• cargo check --target wasm32-unknown-unknown --features workers,encryption --no-default-features ✅
• cargo +1.85 check --all-targets --features "cachekitio,redis,encryption,l1,macros" ✅ (MSRV)

Redis/memcached live-service integration jobs left to CI (need running services).

Summary by CodeRabbit

• Chores
  • Updated an internal component dependency to a newer version while preserving existing functionality.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 9 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e45d5530-40cc-4af3-b821-0c254fc9d2b5

📥 Commits

Reviewing files that changed from the base of the PR and between cc507da and d71b6a7.

📒 Files selected for processing (1)

• crates/cachekit/Cargo.toml

Walkthrough

The cachekit crate updates its cachekit-core dependency from version 0.3 to 0.4 while retaining the messagepack feature.

Changes

Cachekit core dependency update

Layer / File(s)	Summary
Update cachekit-core dependency crates/cachekit/Cargo.toml	The dependency version changes from 0.3 to 0.4; the messagepack feature remains enabled.

Estimated code review effort: 1 (Trivial) | ~2 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: bumping cachekit-core to 0.4.0.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch lab-902-core-0.4.0

---

_{Comment @coderabbitai help to get the list of available commands.}

[kodus-27b]

Kody Review Complete

Great news! 🎉
No issues were found that match your current review configurations.

Keep up the excellent work! 🚀

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​

[27Bslash6]

Expert-panel review — crypto/protocol gate (LAB-902)

The mandatory crypto/protocol expert panel (4 agents, high stakes) has run on this PR. The gate fires because the bump pulls a ByteStorage wire-format change (StorageEnvelope.compressed_data msgpack array-of-ints → bin) into this crate's dependency tree. CI + CodeRabbit do not satisfy this gate, so this is recorded separately.

Verdict: SHIP. One finding applied (d71b6a7); the rest rebutted below.

Crypto gate checkpoints — all CONFIRMED empirically

Checkpoint	Result	Evidence
Key derivation unchanged	✅ CONFIRMED	git diff --name-only cachekit-core-v0.3.0 cachekit-core-v0.4.0 -- src/ returns exactly one file, src/byte_storage.rs. Blob hashes for encryption/key_derivation.rs, encryption/core.rs, encryption/mod.rs are byte-identical across both tags.
AAD independence	✅ CONFIRMED	crates/cachekit/src/encryption.rs:115-154 builds AAD as [0x03][tenant_id][cache_key]["msgpack"]["False"]. The format component is the hardcoded literal b"msgpack" at :116 — never read from StorageEnvelope.format. No envelope bytes, length, or encoding width feed AAD. aad_matches_python still matches the pinned cross-SDK vector.
Ciphertext compatibility, both directions	✅ CONFIRMED	Both trees built and a fixed canary cross-decrypted: 0.4.0-encrypted → decrypts under 0.3.0, and 0.3.0-encrypted → decrypts under 0.4.0. Static Python-generated ciphertext also decrypts under 0.4.0. Rolling deploy is safe in both directions.
bin-length bounds-checking	✅ UNREACHABLE	cachekit_core is referenced at exactly 2 API sites, both in encryption.rs (ZeroKnowledgeEncryptor :18, derive_tenant_keys :68). StorageEnvelope/ByteStorage is never constructed or decoded — under every feature permutation and on wasm32. Defence-in-depth verified anyway: 512 MiB cap at byte_storage.rs:224 precedes rmp_serde::from_slice at :229.

"Encryption-only consumer, zero envelope surface" — premise verified, not assumed. No pub use cachekit_core::… anywhere; EncryptionLayer.encryptor is a private field with no accessor; core errors are flattened to CachekitError::Encryption(String). A downstream crate cannot observe the wire flip through this SDK's public API.

Supply chain — clean. The crates.io artifact for 6aba1513… has src/ byte-identical to the reviewed tag cachekit-core-v0.4.0 (diff -r clean). Zero new transitive deps — serde_bytes was already a non-optional dependency of core at 0.3.0, so the #[serde(with)] attribute added no edge; the only upstream manifest addition is sha2 as a dev-dependency, which does not propagate. Package set identical (286 deps both sides). cargo deny check advisories bans sources → ok; cargo audit output identical pre- and post-bump.

No LAB-900 analogue. In cachekit-py the same bump silently broke an oversize-guard test whose premise rested on the old ~1.5× envelope inflation. That failure class is structurally impossible here: check_payload_size measures bytes.len() from cachekit-rs's own rmp_serde::to_vec_named, never an envelope, and no test or fixture references compressed_data, checksum, lz4, or xxhash.

Finding applied

• crates/cachekit/Cargo.toml:30 — the comment read "cachekit-core 0.2 folds aes-gcm into the encryption feature…" while the pin three lines below now reads 0.4. Raised independently by two panel reviewers. The underlying fact is version-independent and still true at 0.4.0 (wasm is a pure alias for encryption), so the version token was the only part that could rot. De-hardcoded rather than bumped, following the LAB-866 precedent (same class of pinned-version prose removed from cachekit-core's README rather than updated). → d71b6a7

Findings rebutted — deliberately NOT applied

1. features = ["messagepack"] → replace with default-features = false. The diagnosis is correct and confirmed twice: core's default = ["compression", "checksum", "messagepack"] and this dep never sets default-features = false, so the explicit request is redundant, not an expansion — it was already active under 0.3, and removing it changes zero bytes of output. But the proposed fix is a different thing: changing feature resolution on a crypto dependency inside a PR whose entire value is being provably inert would widen the blast radius of a change currently proven behaviour-neutral. It also does not achieve its stated goal — serde_bytes is non-optional upstream, so it survives the slim regardless. Deferred to its own ticket with its own build matrix.

2. build_aad(&self, cache_key, compressed: bool) — the compressed = true branch is unreachable (encrypt :88 and decrypt :99 both pass false literally; only tests reach true). This means a cross-SDK entry written by cachekit-py with compressed=True would not decrypt here. Real, but pre-existing and unrelated to this diff — out of scope for a 3-line dependency bump. Worth its own ticket.

3. deny.toml exists with a real policy but cargo-deny is never invoked — not in .github/workflows/, not in .pre-commit-config.yaml, not in the Makefile. An under-build gap on a public crypto-adjacent SDK (do not "simplify" it by deleting the file). Pre-existing; own ticket. Related pre-existing observation: RUSTSEC-2026-0185 (quinn-proto via reqwest's unactivated HTTP/3 path) is flagged by cargo audit but passed by cargo deny — unchanged by this diff.

4. Add a regression test for the bin encoding / bump crate version / pin = "0.4.0" exactly / flip checksum too — all rejected. Nothing in this crate constructs a StorageEnvelope to assert against (that test belongs in cachekit-core, where LAB-866's panel already put it); release-please owns versioning and CHANGELOG (LAB-866 rejected exactly this); a caret range is correct for a published library — exact-pinning breaks downstream version unification; and the checksum field is a documented normative exclusion (crypto-adjacent, MUST NOT flip) and upstream regardless.

Items 1–3 are pre-existing conditions, not regressions introduced here. Flagging them so they are not lost; none blocks this PR.

@coderabbitai review

[coderabbitai]

@27Bslash6 Thanks for the thorough crypto/protocol gate report. I’ll review PR #53 with the confirmed encryption-only integration boundary, bidirectional ciphertext compatibility evidence, and the explicitly deferred pre-existing items in mind.

---

✏️ Learnings added

Learnt from: 27Bslash6
URL: https://github.com/cachekit-io/cachekit-rs/pull/53

Timestamp: 2026-07-29T02:16:42.527Z
Learning: In the Rust SDK, `crates/cachekit` consumes `cachekit-core` only through `ZeroKnowledgeEncryptor` and `derive_tenant_keys` in `crates/cachekit/src/encryption.rs`; it does not construct, decode, re-export, or publicly expose `cachekit_core::StorageEnvelope` or `cachekit_core::ByteStorage`. Therefore, upstream ByteStorage MessagePack wire-format changes are not observable through this SDK’s public API unless this integration boundary changes.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[27Bslash6]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.