chore(deps): update first-party cachekit #7

kodus-27b · 2026-08-09T21:54:03Z

WHAT: The dependency cachekit-core was bumped from 0.4 to 0.6 with no SCA/CVE evidence. WHY: New/updated dependency versions must be validated for known vulnerabilities and supply-chain risk, and this also breaks the documented version-pin invariant (comment above still says '0.4 matches cachekit-rs 0.7.0's pin'), risking multiple copies in the wasm binary. HOW: Provide OSV/SCA audit output or advisory links in the PR description, confirm the 0.6 version aligns with cachekit-rs 0.7.0's expected pin, update the explanatory comment, and ensure the lockfile is updated accordingly.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File hotpath/Cargo.toml: Line 24: WHAT: The dependency cachekit-core was bumped from 0.4 to 0.6 with no SCA/CVE evidence. WHY: New/updated dependency versions must be validated for known vulnerabilities and supply-chain risk, and this also breaks the documented version-pin invariant (comment above still says '0.4 matches cachekit-rs 0.7.0's pin'), risking multiple copies in the wasm binary. HOW: Provide OSV/SCA audit output or advisory links in the PR description, confirm the 0.6 version aligns with cachekit-rs 0.7.0's expected pin, update the explanatory comment, and ensure the lockfile is updated accordingly.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-08-09T21:54:06Z

WHAT: Bumping the direct cachekit-core dependency to 0.6 while cachekit-rs stays at 0.7.0 breaks the single-copy invariant — Cargo.lock now resolves both cachekit-core 0.4.0 (transitive via cachekit-rs 0.7.0, line 167) and cachekit-core 0.6.0 (direct, line 1187), so two copies of the crate compile into the wasm32 binary. WHY: The in-file comment (lines 21-23) explicitly requires matching cachekit-rs's pin 'so only one copy lands in the wasm binary'; two copies of cachekit-core plus their xxhash-rust/serde_bytes graph inflate the hot-path Worker's wasm size, and the comment now states an incorrect version (still says '0.4 matches'). Additionally, verify_payload (compute.rs:78) documents its checksum as byte-identical to what a cachekit-rs StorageEnvelope embeds; computing it via a different cachekit-core major than cachekit-rs uses removes the guarantee that the two share one checksum implementation. HOW: Either keep cachekit-core pinned to the version cachekit-rs 0.7.0 depends on (0.4), or upgrade cachekit-rs to a release that also depends on cachekit-core 0.6 so a single copy is resolved; update the comment on lines 22-23 accordingly.

# 0.4 matches cachekit-rs 0.7.0's transitive pin so only one copy lands in the wasm binary. cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }

Prompt for LLM

File hotpath/Cargo.toml: Line 24: WHAT: Bumping the direct `cachekit-core` dependency to 0.6 while `cachekit-rs` stays at 0.7.0 breaks the single-copy invariant — Cargo.lock now resolves both `cachekit-core 0.4.0` (transitive via cachekit-rs 0.7.0, line 167) and `cachekit-core 0.6.0` (direct, line 1187), so two copies of the crate compile into the wasm32 binary. WHY: The in-file comment (lines 21-23) explicitly requires matching cachekit-rs's pin 'so only one copy lands in the wasm binary'; two copies of cachekit-core plus their xxhash-rust/serde_bytes graph inflate the hot-path Worker's wasm size, and the comment now states an incorrect version (still says '0.4 matches'). Additionally, `verify_payload` (compute.rs:78) documents its checksum as byte-identical to what a cachekit-rs StorageEnvelope embeds; computing it via a different cachekit-core major than cachekit-rs uses removes the guarantee that the two share one checksum implementation. HOW: Either keep cachekit-core pinned to the version cachekit-rs 0.7.0 depends on (0.4), or upgrade cachekit-rs to a release that also depends on cachekit-core 0.6 so a single copy is resolved; update the comment on lines 22-23 accordingly. Suggested Code: # 0.4 matches cachekit-rs 0.7.0's transitive pin so only one copy lands in the wasm binary. cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-08-09T21:54:09Z

WHAT: Bumping the direct cachekit-core dependency to 0.6 while cachekit-rs stays at 0.7.0 breaks the single-copy invariant the adjacent comment guarantees — Cargo.lock now resolves both cachekit-core 0.6.0 (as skyline-hotpath's direct dep) and cachekit-core 0.4.0 (transitively via cachekit-rs 0.7.0). WHY: Two copies of cachekit-core land in the wasm binary (the outcome the comment on lines 22-23 says the pin prevents), bloating the binary and making the checksum/interop primitives potentially resolve to a different crate instance than the one backing StorageEnvelope, and the comment is now factually wrong. HOW: Either keep cachekit-core at the version cachekit-rs 0.7.0 pins (0.4), or bump cachekit-rs in tandem so both resolve to a single 0.6 copy, then update the comment.

# Keep in lockstep with cachekit-rs's cachekit-core pin so only one copy lands in the wasm binary. cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }

Prompt for LLM

File hotpath/Cargo.toml: Line 24: WHAT: Bumping the direct `cachekit-core` dependency to 0.6 while `cachekit-rs` stays at 0.7.0 breaks the single-copy invariant the adjacent comment guarantees — Cargo.lock now resolves both `cachekit-core 0.6.0` (as skyline-hotpath's direct dep) and `cachekit-core 0.4.0` (transitively via cachekit-rs 0.7.0). WHY: Two copies of `cachekit-core` land in the wasm binary (the outcome the comment on lines 22-23 says the pin prevents), bloating the binary and making the checksum/interop primitives potentially resolve to a different crate instance than the one backing StorageEnvelope, and the comment is now factually wrong. HOW: Either keep `cachekit-core` at the version `cachekit-rs 0.7.0` pins (0.4), or bump `cachekit-rs` in tandem so both resolve to a single 0.6 copy, then update the comment. Suggested Code: # Keep in lockstep with cachekit-rs's cachekit-core pin so only one copy lands in the wasm binary. cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-09-04T05:58:53Z

WHAT: This dependency manifest change bumps cachekit-core from 0.4 to 0.6 with no CVE/SCA evidence. WHY: New/updated dependency versions may introduce known vulnerabilities or supply-chain risk. Additionally, the comment above claims 0.4 matches cachekit-rs 0.7.0's pin, but this changes it to 0.6, which may cause duplicate copies in the wasm binary (contradicting the intent). HOW: Provide OSV/SCA audit output or advisory links in the PR description, pin the exact version, ensure the lockfile is updated, and update the stale comment to reflect the 0.6 pin.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File hotpath/Cargo.toml: Line 24: WHAT: This dependency manifest change bumps cachekit-core from 0.4 to 0.6 with no CVE/SCA evidence. WHY: New/updated dependency versions may introduce known vulnerabilities or supply-chain risk. Additionally, the comment above claims 0.4 matches cachekit-rs 0.7.0's pin, but this changes it to 0.6, which may cause duplicate copies in the wasm binary (contradicting the intent). HOW: Provide OSV/SCA audit output or advisory links in the PR description, pin the exact version, ensure the lockfile is updated, and update the stale comment to reflect the 0.6 pin.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-09-04T05:58:56Z

WHAT: Bumping cachekit-core to "0.6" desyncs it from cachekit-rs 0.7.0's transitive pin of cachekit-core 0.4.0 (confirmed in Cargo.lock:167 vs Cargo.lock:1187), violating the file's own invariant on lines 21-23. WHY: compute.rs:78/85 compute the xxHash3-64 checksum with cachekit-core 0.6.0, but VerifyReport (compute.rs:62-64) contracts this to be byte-identical to the checksum a cachekit-rs StorageEnvelope embeds — which is produced by cachekit-core 0.4.0; a major-version jump can change the hash output, silently breaking integrity verification (matches_expected/xxh3_64 disagree with the stored envelope), and it links two copies of cachekit-core into the wasm binary (Cargo.lock has both 0.4.0 and 0.6.0). HOW: Keep cachekit-core pinned to the version cachekit-rs 0.7.0 depends on (0.4), or upgrade cachekit-rs to a release whose transitive cachekit-core is 0.6 so a single copy resolves; also update the stale "0.4 matches..." comment.

cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }

Prompt for LLM

File hotpath/Cargo.toml: Line 24: WHAT: Bumping cachekit-core to "0.6" desyncs it from cachekit-rs 0.7.0's transitive pin of cachekit-core 0.4.0 (confirmed in Cargo.lock:167 vs Cargo.lock:1187), violating the file's own invariant on lines 21-23. WHY: compute.rs:78/85 compute the xxHash3-64 checksum with cachekit-core 0.6.0, but VerifyReport (compute.rs:62-64) contracts this to be byte-identical to the checksum a cachekit-rs StorageEnvelope embeds — which is produced by cachekit-core 0.4.0; a major-version jump can change the hash output, silently breaking integrity verification (matches_expected/xxh3_64 disagree with the stored envelope), and it links two copies of cachekit-core into the wasm binary (Cargo.lock has both 0.4.0 and 0.6.0). HOW: Keep cachekit-core pinned to the version cachekit-rs 0.7.0 depends on (0.4), or upgrade cachekit-rs to a release whose transitive cachekit-core is 0.6 so a single copy resolves; also update the stale "0.4 matches..." comment. Suggested Code: cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-09-23T09:20:01Z

Checksum mismatch in hotpath/Cargo.toml: bumping cachekit-core to 0.6 while cachekit-rs 0.7.0 depends on 0.4.0 causes two copies to resolve in the wasm binary. When compute.rs:78/85 compute checksums with the 0.6.0 copy, they will not match the StorageEnvelope checksums produced by the 0.4.0 copy inside cachekit-rs (which differ in dependency sets), making VerifyReport.xxh3_64 and matches_expected silently wrong for intact payloads. Keep the direct pin at 0.4 to match cachekit-rs 0.7.0's resolution, or bump cachekit-rs to a release that pins 0.6, and update the comment on lines 22–23 to reflect the single-copy guarantee.

# xxHash3-64 integrity primitive — same function that backs StorageEnvelope # checksums, so wire values are identical. Must stay on the same version # cachekit-rs 0.7.0 resolves (0.4) so only one copy lands in the wasm binary # and checksums are byte-identical to the envelope's. cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }

Prompt for LLM

File hotpath/Cargo.toml: Line 21 to 24: Checksum mismatch in hotpath/Cargo.toml: bumping `cachekit-core` to 0.6 while `cachekit-rs 0.7.0` depends on 0.4.0 causes two copies to resolve in the wasm binary. When `compute.rs:78/85` compute checksums with the 0.6.0 copy, they will not match the `StorageEnvelope` checksums produced by the 0.4.0 copy inside cachekit-rs (which differ in dependency sets), making `VerifyReport.xxh3_64` and `matches_expected` silently wrong for intact payloads. Keep the direct pin at 0.4 to match `cachekit-rs 0.7.0`'s resolution, or bump `cachekit-rs` to a release that pins 0.6, and update the comment on lines 22–23 to reflect the single-copy guarantee. Suggested Code: # xxHash3-64 integrity primitive — same function that backs StorageEnvelope # checksums, so wire values are identical. Must stay on the same version # cachekit-rs 0.7.0 resolves (0.4) so only one copy lands in the wasm binary # and checksums are byte-identical to the envelope's. cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-09-23T09:20:04Z

Missing verification in hotpath/Cargo.toml: the cachekit-core 0.6 bump lacks supply-chain validation and contradicts the comment stating 0.4 aligns with cachekit-rs 0.7.0 to prevent duplicate copies in the wasm binary. Run cargo audit or query OSV for advisories on 0.6, confirm that cachekit-rs 0.7.0 actually resolves to 0.6 (otherwise keep 0.4 or upgrade cachekit-rs), and commit the updated Cargo.lock with the PR.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File hotpath/Cargo.toml: Line 24: Missing verification in hotpath/Cargo.toml: the `cachekit-core` 0.6 bump lacks supply-chain validation and contradicts the comment stating 0.4 aligns with `cachekit-rs 0.7.0` to prevent duplicate copies in the wasm binary. Run `cargo audit` or query OSV for advisories on 0.6, confirm that `cachekit-rs 0.7.0` actually resolves to 0.6 (otherwise keep 0.4 or upgrade `cachekit-rs`), and commit the updated `Cargo.lock` with the PR.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

-Original file line number
+Diff line change
@@ Expand Up / @@ -15,7 +15,7 @@ @@
         "type-check": "tsc --noEmit"
       },
       "dependencies": {
-        "@cachekit-io/cachekit": "0.1.3"
+        "@cachekit-io/cachekit": "0.1.5"
       },
       "devDependencies": {
         "@eslint/js": "^9.39.0",
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -21,7 +21,7 @@ cachekit-rs = { version = "0.7.0", default-features = false } @@
     # xxHash3-64 integrity primitive — same function that backs StorageEnvelope
     # checksums, so wire values are identical. 0.4 matches cachekit-rs 0.7.0's
     # pin so only one copy lands in the wasm binary.
-    cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }
+    cachekit-core = { version = "0.6", default-features = false, features = ["checksum"] }
     serde = { version = "1", features = ["derive"] }
     hex = "0.4"
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -6,7 +6,7 @@ readme = "README.md" @@
     requires-python = ">=3.11"
     license = "MIT"
     dependencies = [
-        "cachekit==0.15.0",
+        "cachekit==0.19.0",
         "websockets>=13",
         "pydantic-settings>=2.6",
     ]
@@ Expand Down @@

Navigation Menu

chore(deps): update first-party cachekit #7

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!

Uh oh!

kodus-27b Bot Aug 9, 2026

Uh oh!

kodus-27b Bot Aug 9, 2026

Uh oh!

kodus-27b Bot Aug 9, 2026

Uh oh!

kodus-27b Bot Sep 4, 2026

Uh oh!

kodus-27b Bot Sep 4, 2026

Uh oh!

kodus-27b Bot Sep 23, 2026

Uh oh!

kodus-27b Bot Sep 23, 2026

Uh oh!

Uh oh!

Uh oh!

chore(deps): update first-party cachekit #7

Are you sure you want to change the base?

Uh oh!

chore(deps): update first-party cachekit #7

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!

Uh oh!

kodus-27b Bot Aug 9, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Aug 9, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Aug 9, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Sep 4, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Sep 4, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Sep 23, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Sep 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!