LAB-427: flip ts Redis TTL/locking matrix cells to implemented - #33
LAB-427: flip ts Redis TTL/locking matrix cells to implemented#3327Bslash6 wants to merge 1 commit into
Conversation
cachekit-ts RedisBackend now implements TTLBackend (TTL/EXPIRE) and LockableBackend (SET NX PX + Lua compare-and-delete, bare-key :lock derivation identical to py) — cachekit-io/cachekit-ts#74. The ts Redis capability gap from the LAB-273 audit is closed; rs (LAB-426) remains. Co-authored-by: multica-agent <github@multica.ai>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 39 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Auto-rebase attempt: merged origin/main and hit real content conflicts in |
|
Auto-rebase check: merging |
…ce reality (#24) * docs: correct SDK feature matrix to code-verified protocol-adherence reality (LAB-272) Audit of py/rs/ts main branches against the four protocol requirements: - Interop mode: merged in cachekit-py (#220) and cachekit-ts (#71), in review for cachekit-rs (#33) — the '❌ Not implemented' row was stale. - Test vectors row now states what each SDK's CI actually executes; wire-format.json and cache-keys.json are verified by no CI anywhere (LAB-423, LAB-425). - Rust keygen cell: caller-supplied keys remain N/A, but the crate exports an unused legacy generate_cache_key matching no protocol format (LAB-424); conformant keygen arrives with cachekit-rs#33. - AAD v0x03 cells record component arity per SDK (py auto serializers emit the optional fifth original_type component; rs/ts/interop are four-component) — byte-identity code-verified per protocol#12. - cachekit-py fleet version 0.11.1 -> 0.12.0. Co-authored-by: multica-agent <github@multica.ai> * docs(matrix): correct Rust keygen footnote — #[cachekit] has no key param and generate_cache_key is not unused [LAB-424] The footnote claimed cachekit-rs delegates key construction via a 'key' parameter on #[cachekit] (no such parameter exists) and called key::generate_cache_key 'unused' (it is called at runtime by every #[cachekit] expansion — proc-macro call sites are invisible to grep). Rewritten to the verified posture: get/set caller-supplied; macro derives an SDK-internal legacy RFC-shape key, made private in cachekit-rs#35 (LAB-424); conformant keygen arrives with #33. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>
|
Auto-rebase attempted a merge of |
|
Auto-rebase sweep: merging |
|
Auto-rebase found a real conflict in |
|
Auto-rebase attempted, left for a human: merging |
…e SDKs (LAB-998) (#46) The repo that this project calls the source of truth for cross-SDK interop still told readers interop/v1 was unimplemented. It has been released in every SDK since 2026-07-24, and the public docs site was already corrected (LAB-996 / cachekit-io/docs#24) — so the normative spec and the docs site contradicted each other, with the spec carrying the false half. Under the project's documentation gate that is a trust bug, not a stale nicety. Three surfaces corrected: - spec/interop-mode.md STATUS header: no longer "NOT yet implemented in any SDK"; states normative + shipped opt-in, with per-registry version floors. - README.md spec table: the "(specified, not yet implemented in any SDK)" parenthetical now points at the feature matrix for per-SDK floors, so the version numbers live in exactly one place. - sdk-feature-matrix.md interop row: "Merged (…, unreleased)" becomes "Released" with floors; Last updated preamble gets this change's entry. Availability is stated as FLOORS (PyPI 0.14.0+, crates.io 0.4.0+, npm 0.1.3+) rather than point-in-time snapshots. This is the lesson from LAB-663, whose seven per-registry snapshots were falsified within 25 minutes of being written when npm published 0.1.3 mid-review. A floor stays true as new versions publish; a snapshot rots on contact. Python's floor is 0.14.0, not the 0.13.0 its changelog implies: interop merged under the v0.13.0 tag, but neither 0.12.0 nor 0.13.0 was ever published to PyPI (verified against the PyPI JSON API — no release keys exist for either), so 0.14.0 is the earliest installable release containing it. Footnote 4 records this so a future reader does not "correct" the floor back to an uninstallable version from the changelog alone. Floors verified 2026-07-28 against live registries and each SDK's release notes: cachekit-py #220 in the v0.13.0 tag (first on PyPI at 0.14.0), cachekit-ts #71 in npm 0.1.3, cachekit-rs #33/#35 in crates.io 0.4.0. Deliberately NOT touched — these say "not yet implemented" and are TRUE: decisions/key-rotation.md, spec/encryption.md:346 and CHANGELOG.md:19 (key rotation, genuinely unimplemented, LAB-516), and the auto-mode non-readability statements in spec/interop-mode.md:50 and spec/wire-format.md (auto-mode is SDK-internal by design). Editing those would introduce a lie. No normative claim changed — availability wording only. No key format, AAD construction, encryption, or wire-format change, so the crypto/protocol expert-panel gate does not apply (same ruling the panel made for this class of edit on LAB-663). verify.yml's full test-vector suite was run locally and is green, as expected for a prose-only diff. Closes LAB-998 Co-authored-by: multica-agent <github@multica.ai>
|
Conflict in |
1 participant
LAB-427: cachekit-ts
RedisBackendnow implementsTTLBackend+LockableBackend(cachekit-io/cachekit-ts#74). This flips the ts Redis TTL-inspect/locking cells to ✅ with module evidence and rewrites the coverage-gap note: py and ts now cover both capabilities on Redis; rs remains TTL-only (LAB-426).Merge after (or together with) cachekit-io/cachekit-ts#74 — the matrix must not claim capability ahead of the shipped SDK.