Cross-SDK drift tracking for cachekit-ts. Surfaced during the 2026-06-06 fleet status review — both items originate outside this repo but require ts action to maintain parity.
1. core 0.2.1 nonce-seed fix → NAPI rebuild (propagation)
cachekit-core has an unreleased security fix (nonce seed) queued in cachekit-core#38 (chore(main): release cachekit-core 0.2.1). Our NAPI package @cachekit-io/cachekit-core-ts pins:
# packages/cachekit-core-ts/Cargo.toml
cachekit-core = { version = "0.2.0", features = ["encryption"] }
Unlike cachekit-py (picks up core via PyO3 dep bump automatically), ts must rebuild + republish the NAPI binary to ship the fix.
Action when core#38 merges + 0.2.1 publishes:
2. lock_id query-string → header (pending protocol decision)
cachekit-py issue #131 flags lock_id leaking via URL query string (CWE-532) and proposes moving it to a request header. ts has the identical pattern:
// packages/cachekit/src/backends/cachekitio-lockable.ts:53
const url = `${this.inner['apiUrl']}/v1/cache/${encodeURIComponent(key)}/lock?lock_id=${encodeURIComponent(lockId)}`;
This is a wire-protocol change — if SaaS moves lock release to a header, all SDKs must follow in lockstep or lock interop breaks. Do not change ts unilaterally. Track py#131 + the SaaS-side decision; implement ts only once the protocol resolution lands.
3. (verify) bare-key lock fix parity
cachekit-py #135 fixed a double-lock 400 (key already carrying :lock). ts's acquireLock passes the key straight to the URL — confirm the SWR/stampede caller feeds it a bare key, not a pre-transformed one.
No ts action is blocked today; items 1–2 are gated on upstream merges/decisions. This issue exists so they don't get lost.
Cross-SDK drift tracking for cachekit-ts. Surfaced during the 2026-06-06 fleet status review — both items originate outside this repo but require ts action to maintain parity.
1. core 0.2.1 nonce-seed fix → NAPI rebuild (propagation)
cachekit-corehas an unreleased security fix (nonce seed) queued in cachekit-core#38 (chore(main): release cachekit-core 0.2.1). Our NAPI package@cachekit-io/cachekit-core-tspins:Unlike cachekit-py (picks up core via PyO3 dep bump automatically), ts must rebuild + republish the NAPI binary to ship the fix.
Action when core#38 merges + 0.2.1 publishes:
cachekit-coreto0.2.1inpackages/cachekit-core-ts/Cargo.toml@cachekit-io/cachekit-core-ts2. lock_id query-string → header (pending protocol decision)
cachekit-py issue #131 flags
lock_idleaking via URL query string (CWE-532) and proposes moving it to a request header. ts has the identical pattern:This is a wire-protocol change — if SaaS moves lock release to a header, all SDKs must follow in lockstep or lock interop breaks. Do not change ts unilaterally. Track py#131 + the SaaS-side decision; implement ts only once the protocol resolution lands.
lock_idto header inreleaseLock(+ acquire if applicable), update protocol tests3. (verify) bare-key lock fix parity
cachekit-py #135 fixed a double-lock 400 (key already carrying
:lock). ts'sacquireLockpasses the key straight to the URL — confirm the SWR/stampede caller feeds it a bare key, not a pre-transformed one.acquireLockfor double-suffix riskNo ts action is blocked today; items 1–2 are gated on upstream merges/decisions. This issue exists so they don't get lost.