Profiles·Public

redis

semver>=5.0.0 <7.0.0postconditions28functions27last verified2026-06-23coverage score100%

Postconditions: what we check

  • createClient · missing-error-listener
    error
    WhencreateClient() called without .on('error', handler) registered
    Required handlingMUST call client.on('error', handler) immediately after createClient(). Handler should log error details and optionally trigger reconnection logic or graceful shutdown.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • connect · connect-no-error-handling
    error
    Whenclient.connect() called without try-catch or .catch() handler
    ThrowsConnection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap await client.connect() in try-catch block. Catch block should check error.code and implement retry logic with exponential backoff for recoverable errors. Non-recoverable errors should trigger graceful shutdown or fallback mode.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • get · get-no-error-handling
    error
    Whenclient.get() called without try-catch or .catch() handler
    ThrowsConnection errors, timeout errors, or WRONGTYPE errors
    Required handlingMUST wrap await client.get() in try-catch block. For connection errors, implement graceful degradation (fallback to database). For WRONGTYPE errors, fix data schema. For timeout errors, retry with backoff or return cached/default value.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • set · set-no-error-handling
    error
    Whenclient.set() called without try-catch or .catch() handler
    ThrowsConnection errors, timeout errors, or command errors
    Required handlingMUST wrap await client.set() in try-catch block. For connection errors, consider queueing write for retry. For critical writes, re-throw error to caller. For non-critical cache writes, log error and continue without cache.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • del · del-no-error-handling
    error
    Whenclient.del() called without try-catch or .catch() handler
    ThrowsConnection errors or timeout errors
    Required handlingMUST wrap await client.del() in try-catch block. For connection errors, log error and decide whether to retry, fail operation, or continue. Critical deletes should re-throw error to caller for proper handling.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • hSet · hset-no-error-handling
    error
    Whenclient.hSet() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE when key exists as non-hash), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN), SocketClosedUnexpectedlyError
    Required handlingMUST wrap await client.hSet() in try-catch. Check err.message.includes('WRONGTYPE') to distinguish type errors from connection errors. Type errors indicate a data schema bug; connection errors may be retried.
    costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
    Sources[1][2]
  • hGet · hget-no-error-handling
    error
    Whenclient.hGet() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE if key is not a hash), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap await client.hGet() in try-catch. Return null fallback for missing fields is correct — do not confuse this with thrown errors.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][3]
  • hGetAll · hgetall-no-error-handling
    error
    Whenclient.hGetAll() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE if key is not a hash), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap in try-catch. Also check if the returned object is empty ({}) to detect missing sessions/profiles — returning {} is not an error but often indicates "not found" semantics.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][4]
  • incr · incr-no-error-handling
    error
    Whenclient.incr() called without try-catch or .catch() handler
    ThrowsErrorReply ("ERR value is not an integer or out of range") when key holds a non-integer string; connection errors (ECONNREFUSED, ETIMEDOUT)
    Required handlingMUST wrap await client.incr() in try-catch. Check err.message for "not an integer" to distinguish type errors (data schema bug) from connection errors (retriable).
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][5]
  • incrBy · incrby-no-error-handling
    error
    Whenclient.incrBy() called without try-catch or .catch() handler
    ThrowsErrorReply ("ERR value is not an integer or out of range") when key holds a non-integer; connection errors (ECONNREFUSED, ETIMEDOUT)
    Required handlingMUST wrap await client.incrBy() in try-catch. Same handling as incr().
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][6]
  • expire · expire-no-error-handling
    error
    Whenclient.expire() called without try-catch or .catch() handler
    ThrowsConnection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN); ErrorReply on invalid argument types
    Required handlingMUST wrap await client.expire() in try-catch. Prefer atomic client.set(key, value, {EX: ttl}) to avoid the set-then-expire race condition entirely. If separate expire() is required, log and alert on failure — persistent keys are a security and memory risk.
    costmediumin prodimmediate exceptionusers seedegraded performancevisibilitysilent
    Sources[1][7]
  • exists · exists-no-error-handling
    error
    Whenclient.exists() called without try-catch or .catch() handler
    ThrowsConnection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap await client.exists() in try-catch. Distinguish connection errors from logic errors. For cache-pattern guards, fail safe (treat as "not exists" and proceed to authoritative source).
    costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • lPush · lpush-no-error-handling
    error
    Whenclient.lPush() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE if key is not a list), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap await client.lPush() in try-catch. For queue patterns, re-throw so callers can handle job failure. Check err.message.includes('WRONGTYPE') to detect key type collisions.
    costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
    Sources[1][8]
  • lRange · lrange-no-error-handling
    error
    Whenclient.lRange() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE if key is not a list), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap await client.lRange() in try-catch. An empty array is a valid result, not an error condition. Check for ErrorReply type to distinguish Redis server errors from connection errors.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][9]
  • sAdd · sadd-no-error-handling
    error
    Whenclient.sAdd() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE if key is not a set), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap await client.sAdd() in try-catch. For deduplication, re-throw on error to prevent silent data loss. Log WRONGTYPE errors — they indicate a key namespace collision that requires investigation.
    costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
    Sources[1][10]
  • sMembers · smembers-no-error-handling
    error
    Whenclient.sMembers() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE if key is not a set), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap await client.sMembers() in try-catch. An empty Set is a valid result. WRONGTYPE errors indicate data schema problems requiring code investigation.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][11]
  • zAdd · zadd-no-error-handling
    error
    Whenclient.zAdd() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE if key is not a sorted set; "not a float" if score is NaN/Infinity), connection errors (ECONNREFUSED, ETIMEDOUT)
    Required handlingMUST wrap await client.zAdd() in try-catch. Validate score is a finite number before passing to zAdd(). WRONGTYPE indicates a key collision; score errors indicate a computation bug upstream.
    costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
    Sources[1][12]
  • zRange · zrange-no-error-handling
    error
    Whenclient.zRange() called without try-catch or .catch() handler
    ThrowsErrorReply (WRONGTYPE if key is not a sorted set), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN)
    Required handlingMUST wrap await client.zRange() in try-catch. An empty array is a valid result. Implement fallback for connection errors in leaderboard reads (return cached or empty data rather than throwing to the user).
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][13]
  • exec · multi-exec-watch-error
    error
    Whenclient.watch() was used and the watched key was modified by another client before exec() was called; or client reconnected after WATCH
    ThrowsWatchError (from @redis/client) — thrown from exec() when optimistic locking fails. The transaction was not executed.
    Required handlingMUST wrap exec() in try-catch when WATCH is used. Check err instanceof WatchError to implement retry logic. WatchError means the transaction was not executed — not a partial execution. Retry the full WATCH+MULTI+EXEC sequence.
    costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
    Sources[14][15]
  • exec · multi-exec-connection-error
    error
    WhenConnection is lost or client is closed before exec() completes
    ThrowsSocketClosedUnexpectedlyError, ClientClosedError, or connection system errors (ECONNREFUSED, ECONNRESET)
    Required handlingMUST wrap exec() in try-catch. On connection error, the transaction state is unknown — implement reconciliation logic or re-read state before retrying.
    costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
    Sources[14][1]
  • subscribe · subscribe-no-error-handling
    error
    Whenclient.subscribe() called without try-catch or .catch() handler
    ThrowsClientClosedError (if client is not connected), connection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET) on network failure during subscription
    Required handlingMUST wrap await client.subscribe() in try-catch for connection failure. The client .on('error') listener handles ongoing connection errors after subscription. Both patterns are required: try-catch for subscribe() AND .on('error') on client.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][16]
  • publish · publish-no-error-handling
    error
    Whenclient.publish() called without try-catch or .catch() handler
    ThrowsConnection errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN); ClientClosedError if client is disconnected
    Required handlingMUST wrap await client.publish() in try-catch. A return value of 0 is NOT an error — do not throw or retry based on the count alone. Only throw on connection errors or when guaranteed delivery is required (use a different pattern such as streams for guaranteed delivery).
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][17]
  • quit · quit-no-error-handling
    warning
    Whenclient.quit() called without try-catch or .catch() handler
    ThrowsConnection errors if the connection is already closed or lost before QUIT completes; SocketClosedUnexpectedlyError
    Required handlingSHOULD wrap await client.quit() in try-catch in shutdown handlers. Errors during quit() can be logged and swallowed — the connection is being torn down anyway. Use `client.quit().catch(err => logger.warn('Redis quit error', err))` pattern.
    costlowin prodimmediate exceptionusers seedegraded performancevisibilityvisible
    Sources[1][18]
  • close · close-no-error-handling
    warning
    Whenclient.close() called without try-catch or .catch() handler
    ThrowsClientClosedError if close() is called twice; connection-layer errors (ECONNRESET, ETIMEDOUT) if the socket dies during the graceful drain; unhandled promise rejection on any of the above
    Required handlingSHOULD wrap await client.close() in try-catch in shutdown handlers. Errors during close() can be logged and swallowed — the connection is being torn down anyway. Use the same pattern as quit(): `client.close().catch(err => logger.warn('Redis close error', err))`. For graceful shutdown sequencing, await close() before terminating the process so pending commands flush.
    costlowin prodimmediate exceptionusers seedegraded performancevisibilityvisible
    Sources[19][1]
  • watch · watch-no-error-handling
    error
    Whenclient.watch() called without try-catch or .catch() handler
    ThrowsConnection-layer errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN); ClientClosedError if the client was closed before watch() ran
    Required handlingMUST wrap await client.watch() in try-catch. On error, ABORT the entire transaction — do NOT proceed to multi().exec(). The exec() WatchError handler covers the "watched key changed" case; this handler covers the "watch() itself failed" case. Both are required for correct optimistic locking. Pattern: try { await client.watch('counter'); const value = await client.get('counter'); await client.multi().set('counter', String(Number(value) + 1)).exec(); } catch (err) { if (err instanceof WatchError) { /* retry: key changed */ } else { /* abort: watch or exec failed */ } }
    costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
    Sources[14][15]
  • createClientPool · create-client-pool-no-error-handling
    error
    WhencreateClientPool() factory called without a corresponding pool.on('error') listener AND without try-catch on the subsequent pool.connect()
    Throwspool.connect() throws on connection failure (ECONNREFUSED, ETIMEDOUT, DNS failures); pool runtime errors are dispatched as 'error' events on the pool — uncaught events crash the process by default
    Required handlingMUST register pool.on('error', handler) BEFORE calling pool.connect(), and MUST wrap await pool.connect() in try-catch. Pattern mirrors the createClient() / connect() / .on('error') triad — same rules apply.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[19][14]
  • execute · pool-execute-no-error-handling
    error
    Whenpool.execute(callback) called without try-catch or .catch() handler
    ThrowsWatchError (when callback uses WATCH+MULTI and the watched key was modified); any error thrown by the callback itself; connection-layer errors on the isolated client (ECONNREFUSED, ECONNRESET); ClientClosedError if the pool is closed mid-execute
    Required handlingMUST wrap await pool.execute(...) in try-catch. Discriminate by error type: WatchError → retry the callback (the watched key changed, this is the designed retry signal). Other errors → fail the operation and log. The isolated client is returned to the pool regardless of outcome — do NOT attempt to close it inside the callback. Pattern: try { await pool.execute(async (client) => { await client.watch('key'); const v = await client.get('key'); return client.multi().set('key', updated(v)).exec(); }); } catch (err) { if (err instanceof WatchError) { /* retry */ } else { throw err; } }
    costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
    Sources[14]
  • sendCommand · send-command-no-error-handling
    error
    Whenclient.sendCommand() called without try-catch or .catch() handler
    ThrowsErrorReply / SimpleError when Redis returns an error response (WRONGTYPE, NOSCRIPT, READONLY, MOVED, ASK, MASTERDOWN, etc.); connection-layer errors (ECONNREFUSED, ETIMEDOUT, ECONNRESET); ClientClosedError if the client is disconnected; AbortError if an AbortSignal was attached and aborted
    Required handlingMUST wrap await client.sendCommand() in try-catch. Inspect err.name === 'ReplyError' to handle Redis-level errors (WRONGTYPE, NOSCRIPT, etc.) distinctly from connection-layer errors. If using AbortSignal, also handle AbortError. For commands that mutate state, the safe pattern is: catch → log → re-raise so the caller can decide whether to retry or fail the request.
    costmediumin prodimmediate exceptionusers seelost datavisibilitysilent
    Sources[1]

Sources

Every postcondition cites at least one of these. Grouped by source type; numbered to match the footnotes above.

Official documentation
  • [1]
    redis.io/docs/latest/develop
    Error Handling
  • [2]
    redis.io/commands/hset
    Hset
  • [3]
    redis.io/commands/hget
    Hget
  • [4]
    redis.io/commands/hgetall
    Hgetall
  • [5]
    redis.io/commands/incr
    Incr
  • [6]
    redis.io/commands/incrby
    Incrby
  • [7]
    redis.io/commands/expire
    Expire
  • [8]
    redis.io/commands/lpush
    Lpush
  • [9]
    redis.io/commands/lrange
    Lrange
  • [10]
    redis.io/commands/sadd
    Sadd
  • [11]
    redis.io/commands/smembers
    Smembers
  • [12]
    redis.io/commands/zadd
    Zadd
  • [13]
    redis.io/commands/zrange
    Zrange
  • [14]
    redis.io/docs/latest/develop
    Transpipe
  • [15]
    redis.io/commands/watch
    Watch
  • [16]
    redis.io/commands/subscribe
    Subscribe
  • [17]
    redis.io/commands/publish
    Publish
  • [18]
    redis.io/commands/quit
    Quit
Source code

Research notes

Curator notes from SOURCES.md captured when the profile was written so you can verify the reasoning, not just the rules.

Sources: redis

This document tracks all research sources used to create the Nark profile for the redis npm package (node-redis v5).


Official Documentation

Primary Error Handling Documentation

  • URL: https://redis.io/docs/latest/develop/clients/nodejs/error-handling/
  • Date Accessed: 2026-02-25
  • Key Findings:
    • MUST register error event listener or process will crash
    • Common error types: ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN
    • ReplyError types: WRONGTYPE (non-recoverable), BUSY/TRYAGAIN/LOADING (retry with backoff)
    • Four error handling patterns: fail fast, graceful degradation, retry with backoff, log and continue

v4 to v5 Migration Guide

  • URL: https://github.com/redis/node-redis/blob/master/docs/v4-to-v5.md
  • Date Accessed: 2026-02-25
  • Key Changes:
    • client.quit() → client.close() (graceful shutdown)
    • client.disconnect() → client.destroy() (force disconnect)
    • Pipeline behavior: v5 discards unwritten commands on disconnect (more predictable)
    • Return type changes: Many commands now return number instead of boolean

npm Package Page

  • URL: https://www.npmjs.com/package/redis
  • Date Accessed: 2026-02-25
  • Current Version: 5.11.0 (as of 2026-02-25)
  • Key Info: Promise-based API, TypeScript support, automatic reconnection

GitHub Repository


Real-World Usage Analysis

parse-server (v5.10.0)

  • Repository: https://github.com/parse-community/parse-server
  • Files Analyzed:
    • src/Adapters/Cache/RedisCacheAdapter.js
    • src/Adapters/PubSub/RedisPubSub.js
  • Patterns Observed:
    • ✅ Good: Error listener registered on createClient
    • ✅ Good: get() wrapped in try-catch
    • ❌ Bad: put(), del(), clear() NOT wrapped in try-catch
    • Connection management: connect(), close()
    • Queue pattern for operation sequencing

nestjs

  • Repository: https://github.com/nestjs/nest
  • Files Analyzed:
    • integration/microservices/e2e/broadcast-redis.spec.ts
    • integration/microservices/e2e/sum-redis.spec.ts
  • Patterns Observed:
    • Redis used via Transport.REDIS abstraction
    • Connection management handled by framework
    • Host/port configuration pattern

typeorm

  • Repository: https://github.com/typeorm/typeorm
  • Files Analyzed:
    • src/cache/RedisQueryResultCache.ts
    • src/platform/PlatformTools.ts
  • Patterns Observed:
    • Redis as optional dependency
    • Dynamic require() pattern
    • Cache abstraction layer

Error Categories

1. Connection Errors (Recoverable)

  • ECONNREFUSED: Connection refused - Redis server not running or not reachable
  • ETIMEDOUT: Command timeout - Network latency or server overload
  • ECONNRESET: Connection reset by peer - Network interruption
  • EAI_AGAIN: DNS resolution failure - Temporary DNS issue

Recommended Handling: Retry with exponential backoff, fallback to alternative data source

2. Command Errors (Non-Recoverable)

  • WRONGTYPE: Type mismatch - Attempting wrong operation on key type
    • Example: LPUSH on a string key
    • Fix: Correct the data schema or command

Recommended Handling: Fail fast, fix code or data

3. Command Errors (Recoverable with Bounded Retry)

  • BUSY: Redis is busy (e.g., during BGSAVE)
  • TRYAGAIN: Command failed, can retry (e.g., cluster redirect)
  • LOADING: Redis is loading data from disk

Recommended Handling: Retry with exponential backoff (bounded attempts)

4. Error Events (Critical)

  • No error listener: If client doesn't have at least one error listener registered, any error will be thrown and the Node.js process will exit
  • AbortError: Command not yet executed but rejected
  • InterruptError: Executed commands that failed (e.g., network drop during execution)

Recommended Handling: ALWAYS register error listener on createClient


Security Research

CVE Analysis

  • Search Date: 2026-02-25
  • Finding: No CVEs found for node-redis npm package client library
  • Note: Redis server CVEs (CVE-2025-49844, CVE-2025-21605) are not relevant to client behavior

Conclusion: Focus on error handling best practices rather than security vulnerabilities


Error Handling Patterns

Pattern 1: Fail Fast (Non-Recoverable Errors)

try {
  await client.get(key);
} catch (err) {
  if (err.name === 'ReplyError' && /WRONGTYPE|ERR /.test(err.message)) {
    throw err; // Fix code or data type
  }
  throw err;
}

Pattern 2: Graceful Degradation (Connection Errors)

try {
  const val = await client.get(key);
  if (val != null) return val;
} catch (err) {
  if (['ECONNREFUSED','ECONNRESET','ETIMEDOUT','EAI_AGAIN'].includes(err.code)) {
    logger.warn('Cache unavailable; falling back to DB');
    return database.get(key);
  }
  throw err;
}
return database.get(key);

Pattern 3: Retry with Backoff (Temporary Errors)

async function getWithRetry(key, { attempts = 3, baseDelayMs = 100 } = {}) {
  let delay = baseDelayMs;
  for (let i = 0; i < attempts; i++) {
    try {
      return await client.get(key);
    } catch (err) {
      if (
        i < attempts - 1 &&
        (['ETIMEDOUT','ECONNRESET','EAI_AGAIN'].includes(err.code) ||
         (err.name === 'ReplyError' && /(BUSY|TRYAGAIN|LOADING)/.test(err.message)))
      ) {
        await new Promise(r => setTimeout(r, delay));
        delay *= 2;
        continue;
      }
      throw err;
    }
  }
}

Pattern 4: Log and Continue (Non-Critical Operations)

try {
  await client.setEx(key, 3600, value);
} catch (err) {
  if (['ECONNREFUSED','ECONNRESET','ETIMEDOUT','EAI_AGAIN'].includes(err.code)) {
    logger.warn(`Failed to cache ${key}, continuing without cache`);
  } else {
    throw err;
  }
}

Nark profile Rationale

Why These Functions?

  1. createClient(): Entry point - error listener is critical for process stability
  2. client.connect(): Connection establishment - common point of failure (ECONNREFUSED, ETIMEDOUT)
  3. client.get(): Most common read operation - connection/timeout errors
  4. client.set(): Most common write operation - data loss risk without error handling
  5. client.del(): Common deletion operation - connection errors

Why These Postconditions?

  1. missing-error-listener (ERROR):

    • Without error listener, ANY error will crash the Node.js process
    • Severity: ERROR - process crash is unacceptable
    • Real-world evidence: All production code registers error listeners
  2. connect-no-error-handling (ERROR):

    • Connection failures are common (server down, network issues)
    • Unhandled promise rejection can crash process
    • Severity: ERROR - application cannot function without connection handling
  3. get-no-error-handling (ERROR):

    • Read operations critical for application logic
    • Unhandled errors cause crashes or incorrect behavior
    • Severity: ERROR - must handle connection/timeout errors
  4. set-no-error-handling (ERROR):

    • Write operations risk data loss without error handling
    • Silent failures can corrupt application state
    • Severity: ERROR - data integrity depends on error handling
  5. del-no-error-handling (ERROR):

    • Deletion operations affect application state
    • Unhandled errors can lead to inconsistent state
    • Severity: ERROR - state consistency requires error handling

Deferred for Future Versions

  • Pub/Sub patterns: subscribe(), publish(), pSubscribe()
  • Transaction commands: multi(), exec(), watch()
  • Pipeline operations: Batched command execution
  • Cluster support: Cluster-specific commands and error handling
  • Stream commands: xAdd(), xRead(), xRange()
  • Advanced commands: keys(), scan(), eval()

Rationale: Starting with core CRUD operations that cover 80% of use cases


Version Compatibility

  • Target Version Range: ^5.0.0
  • Tested Against: v5.10.0, v5.11.0
  • Breaking Changes from v4:
    • API method renames (quit→close, disconnect→destroy)
    • Pipeline behavior changes
    • Return type changes (boolean→number)

References

  1. Error handling | Redis Node.js Docs
  2. node-redis v4 to v5 Migration
  3. redis - npm
  4. GitHub - redis/node-redis
  5. parse-server RedisCacheAdapter
  6. NestJS Redis Transport
  7. TypeORM Redis Cache

Last Updated: 2026-02-25 Researcher: Claude Sonnet 4.5 Contract Version: 1.0.0

Need a different package?
Request a profile