Skip to content

Track DialCache deep-review follow-up work #47

Description

@lan17

Priority

META — Tracking — umbrella only; not implementation work.

Context

This tracks follow-up from the deep API, performance, scalability, and correctness review originally performed against main@2bda04d1443a75a71cbbc41365c4424554936a37.

Current status: main@9360d757ebf41252624e7e6f6b208b292ed643d9, released as https://github.com/lan17/DialCache/releases/tag/v0.5.0 and published as dialcache@0.5.0. Post-merge CI https://github.com/lan17/DialCache/actions/runs/29663133306 and release workflow https://github.com/lan17/DialCache/actions/runs/29663163960 passed. Twenty of 39 tracked issues are resolved, 19 implementation issues remain open, and every P0 is closed.

Confirmed behavior and architecture decisions are recorded explicitly in their implementation issues. Completed and explicitly closed-not-planned items are checked below. All remaining open decisions must still receive maintainer approval before implementation.

Priority rubric

  • P0 — Critical: resolve before the next release presented as production-ready.
  • P1 — High: resolve before broad production adoption or large-scale use.
  • P2 — Medium: important hardening or API work after the safety foundations.
  • P3 — Low: later or demand-driven enhancement.

Current grooming recommendation

No remaining issue blocks a controlled trial that uses static/default configuration or complete runtime policies. The confirmed partial-overlay contract is implemented in draft #68 and remains pending review and merge.

  1. Review and merge feat: overlay runtime cache configuration on defaults #68 to complete Overlay runtime cache configuration on documented defaults #23; after that, Prevent Redis outages from amplifying latency, source load, and logs #38 is the next general production-hardening target.
  2. Treat Prevent Redis outages from amplifying latency, source load, and logs #38 as the clearest subsequent outage hardening: avoid a second Redis attempt after a failed read while leaving timeout, retry, reconnect, queueing, and log policy caller-owned.
  3. Resolve Align runtime support after Node 20 EOL #34 as compatibility hygiene before broad adoption by choosing the exact maintained Node 22+ floor.
  4. Treat Bound and observe in-process single-flight state #41 and Characterize and guard watermark cardinality and Redis Cluster hot slots #42 as workload-gated checks: first enforce finite caller-owned Redis/fallback time budgets and measure tracked-ID rate, watermark lifetime, and hottest-ID QPS; add core machinery only if those measurements justify it.
  5. Treat Recover safely from corrupt tracked watermark state #31, Validate TTL and invalidation duration arithmetic consistently #33, Add a repeatable performance and scale benchmark suite #35, Make zero local capacity consistent and evaluate byte-aware limits #40, and Establish a local-hit performance budget and remove avoidable hot-path work #43 as focused hardening or measurement work rather than initial-trial blockers.
  6. Keep Add thresholded client-side compression for Redis payloads #60 at P3: compression is deliberately punted until production payload observations justify its format, CPU, and rollout complexity.
  7. Candidate not-planned closures awaiting explicit maintainer approval: Design a first-class typed cache-definition handle #21, Rationalize the root export surface and scope-method vocabulary #24, Add request-boundary helpers and missing-scope diagnostics #25, Keep runtime configuration lookup cheap and bounded #39, and Design batch reads and invalidations without one Redis script per key #46.

P0 — Critical

P1 — High

P2 — Medium

P3 — Low

Dependency notes

Completion standard

  • Every implementation issue includes focused unit/integration/type tests for its failure mode.
  • Breaking changes include migration and mixed-version/rollback notes.
  • Performance work reports reproducible before/after results.
  • No design issue is implemented until its open decisions are explicitly approved.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions