feat: add Valkey GLIDE adapter#11
Merged
Merged
Conversation
f837bfe to
9c6f4fd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add first-party Valkey GLIDE support without coupling DialCache core to a particular Redis client.
The new
dialcache/valkey-glidesubpath wraps an already-created standalone or cluster GLIDE client. DialCache continues to depend only on the semanticDialCacheRedisClientboundary and preserves the existing version-1 Redis wire frame.Design
Client ownership
Applications remain responsible for creating, configuring, connecting, and closing their GLIDE client. The adapter owns only its five native GLIDE
Scripthandles and exposes an idempotentdispose()method to release them after outstanding cache operations complete.Disposal rejects while script invocations are in flight, preventing GLIDE's local script source from being released during automatic
NOSCRIPTrecovery.Script execution and payloads
The adapter:
ScriptAPI;Decoder.Bytesreplies so arbitrary serializer output remains lossless;flushAll().The payload encoding selector and response-frame decoder live in a small internal helper shared by node-redis and GLIDE. Client-specific invocation and lifecycle behavior remain in their respective adapters.
Package surface
dialcache/valkey-glideESM, CJS, and declaration exports.@valkey/valkey-glide@^2.4.2as an optional peer dependency.20 || >=22support contract.Test architecture
Adapter conformance runs node-redis and Valkey GLIDE against one Redis 6.2 standalone server. This validates DialCache's adapter boundary at the oldest server version supported by GLIDE without duplicating GLIDE's upstream Redis/Valkey compatibility matrix.
The shared suite covers UTF-8, arbitrary binary and tracked payloads, invalidation, malformed frames, automatic script-cache recovery, full DialCache serializer use, flush behavior, and node-redis/GLIDE cross-client wire compatibility.
Unit tests validate GLIDE-specific argument construction, byte decoding, reply validation, explicit all-primary cluster flush routing, script disposal, and in-flight disposal protection. The repository's node-redis Redis/Valkey protocol matrix and Redis Cluster integration suite remain covered.
Rebase integration
The branch is rebased onto main commit
24ca4eeb3da3450c118b88af868ffd1938f6f4eb, which added the bounded local LRU and raised the Node support floor. The README conflict was resolved by retaining both the global local-cache documentation and the GLIDE adapter behavior.Validation
pnpm check— typecheck, 106 unit tests with coverage thresholds, build, and packaged ESM/CJS/TypeScript consumerspnpm test:integration— 48 Docker-backed integration testspnpm audit --prod— no known vulnerabilitiesgit diff --check