Skip to content

LAB-427: flip ts Redis TTL/locking matrix cells to implemented - #33

Open
27Bslash6 wants to merge 1 commit into
mainfrom
lab-427-ts-redis-matrix
Open

LAB-427: flip ts Redis TTL/locking matrix cells to implemented#33
27Bslash6 wants to merge 1 commit into
mainfrom
lab-427-ts-redis-matrix

Conversation

@27Bslash6

Copy link
Copy Markdown
Contributor

LAB-427: cachekit-ts RedisBackend now implements TTLBackend + 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.

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>
@coderabbitai

coderabbitai Bot commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

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: 39 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: d7780094-7ef5-4116-8bd3-75e8f6885b2b

📥 Commits

Reviewing files that changed from the base of the PR and between 8ba5ef9 and 871be5c.

📒 Files selected for processing (1)
  • sdk-feature-matrix.md
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch lab-427-ts-redis-matrix

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

@27Bslash6

Copy link
Copy Markdown
Contributor Author

Auto-rebase attempt: merged origin/main and hit real content conflicts in sdk-feature-matrix.md — this branch (LAB-427, ts Redis TTL/locking) claims Rust's Redis distributed locking is , while main's current version already shows it as (LAB-426, landed via another PR). Contradictory facts in the same capability cells, not a non-overlapping union. Left for a human call. Merge aborted, branch untouched.

@27Bslash6

Copy link
Copy Markdown
Contributor Author

Auto-rebase check: merging origin/main into this branch conflicts in sdk-feature-matrix.md across 4 hunks. Looking at main's content, this PR's exact goal (LAB-427: flip TS Redis TTL/lock capability cells to ✅) already appears to have landed on main — bundled together with LAB-426/LAB-429/LAB-519/LAB-446/LAB-595 in a later matrix update. All four conflicting hunks show main's TS Redis TTL/lock entries already ✅ with the LAB-427 citation. This looks like it may just need closing as superseded rather than rebased — leaving for a human call since confirming "superseded" from doc content is a judgment call, not a mechanical merge.

27Bslash6 added a commit that referenced this pull request Jul 25, 2026
…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>
@27Bslash6

Copy link
Copy Markdown
Contributor Author

Auto-rebase attempted a merge of origin/main and found a genuine content conflict in sdk-feature-matrix.md — both sides edited the same capability-matrix rows with contradicting claims (e.g. this branch says Rust Redis distributed locking is , origin/main says ✅ (LAB-426)). Resolving would mean picking one side's data over the other's, so left for a human call.

@27Bslash6

Copy link
Copy Markdown
Contributor Author

Auto-rebase sweep: merging main conflicts in sdk-feature-matrix.md. This branch (LAB-427, TS Redis TTL/locking) and main both edited the TTL inspect/refresh and Distributed locking rows for overlapping SDK columns with different, non-union content (main already folds in this same LAB-427 change plus LAB-426/LAB-430/LAB-446/LAB-519 on top), plus conflicting "Last updated"/footnote text. Not a safe mechanical union. Left for a human to reconcile — worth checking whether this PR is now superseded by main's already-merged state.

@27Bslash6

Copy link
Copy Markdown
Contributor Author

Auto-rebase found a real conflict in sdk-feature-matrix.md — needs a human call. Same hot file as the other open matrix PRs (LAB-426/430/etc): main's changelog line already says "LAB-427: ts Redis lock/TTL capability cells refreshed", so this branch's edit may already be superseded or duplicated on main rather than a clean addition — can't tell which claims are current without a human read. Left the branch as-is; will retry once main moves again.

@27Bslash6

Copy link
Copy Markdown
Contributor Author

Auto-rebase attempted, left for a human: merging main conflicts in sdk-feature-matrix.md — same "Last updated" line, TTL-inspect/distributed-locking table rows, and coverage footnote edited on both sides with different ticket-driven content (this branch: LAB-427 ts Redis TTL+locking; main: LAB-729/LAB-519/LAB-446/LAB-430/LAB-426 updates). Needs a human to synthesize both sets of matrix edits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant