Skip to content

1.0 API polish: del() alias, native Redis has/getTtl, listener error visibility #59

Description

@camcima

Deferred from the architecture review (finding L8) — see ARCHITECTURE_REVIEW.md. Three small independent items, grouped because each is churn on its own and they are all best done in one deliberate API pass before 1.0.

1. Drop the del() alias

CacheManager.del() (packages/core/src/cache-manager.ts:278) is a pure passthrough to delete(). Two names for one operation is surface to document, test, and keep working forever; this is the cheapest moment to pick one. delete() matches the adapter interface, so del() is the one to go.

Breaking, and currently documented in docs/api-reference.md — needs a BREAKING CHANGE: footer and a changelog note if removed.

2. Let Redis answer has() and getTtl() natively

RedisAdapter inherits both from BaseCacheAdapter (packages/core/src/base-cache-adapter.ts:64,68), which implements them as a full get() — fetching and JSON-parsing the whole value to answer a question EXISTS or PTTL answers directly. Wasteful for large cached payloads.

The catch: the base implementations enforce the envelope expiresAt check, and EXISTS/PTTL would only see Redis's own TTL. Those agree except under clock skew between writer and reader — the same asymmetry that #56 made non-destructive. Worth confirming that trade is acceptable before optimizing; it may be, since Redis's TTL is the authoritative one.

3. Make swallowed listener errors visible in development

TypedEventEmitter.emit() catches and discards listener exceptions (packages/core/src/event-emitter.ts:28). Correct — a broken metrics listener must not break caching — but it means a listener that throws on its first call is silently inert forever, with nothing to debug.

An opt-in escape hatch (an onListenerError callback on the emitter, or a debug flag) would keep the production guarantee while making the failure findable.

Done when

Each item is either implemented or explicitly declined with the reasoning recorded — they are independent, so partial completion is fine.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions