Files
zeekay 6994cf05aa kv, not redis: rename the package, the extras and the URL scheme
We do not use Redis. The client was a go-redis fork and still said so
everywhere: `package redis`, `redis.NewClient`, `redis://`, `extra/redisotel`.
Consumers wrote `redis.Client` against a Valkey-backed store called KV.

  package redis            -> package kv          (93 decls)
  redis.X                  -> kv.X                (2,794 call sites)
  "redis: …" errors        -> "kv: …"             (206)
  extra/redis{otel,cmd,prometheus,census} -> extra/kv{otel,cmd,prometheus,census}
  redis:// , rediss://     -> kv:// , kvs://      (ParseURL)
  Redis*/‌*Redis* idents    -> KV*/*KV*
  REDIS_VERSION, REDIS_ENDPOINTS_CONFIG_PATH -> KV_*

I previously argued this rename was unsafe because much of it was "wire
contract". That was wrong, and the categorisation shows why: RESP command names
are GET/SET/HSET — they never contain the word. Of 5,771 occurrences only two
kinds were server-visible at all: the ParseURL scheme (we choose what we pass;
our configs already use kv://) and the CLIENT SETINFO lib-name label, which the
server merely records. Nothing here changes a byte of protocol.

Two things deliberately keep the old spelling:
  RediSearch  — names a specific external module the FT.* commands map to.
  StoreDist   — contains the letters by accident (sto-reDis-t), not the word.

Breaking for consumers by design: every import site must move redis.X -> kv.X.
Minor bump, never a major — this module stays v9 forever.
2026-07-26 08:34:19 -07:00
..

Maintenance Notifications

Seamless KV connection handoffs during cluster maintenance operations without dropping connections.

⚠️ Important Note

Maintenance notifications are currently supported only in standalone KV clients. Cluster clients (ClusterClient, FailoverClient, etc.) do not yet support this functionality.

Quick Start

client := kv.NewClient(&kv.Options{
    Addr:     "localhost:6379",
    Protocol: 3, // RESP3 required
	MaintNotificationsConfig: &maintnotifications.Config{
        Mode: maintnotifications.ModeEnabled,
    },
})

Modes

  • ModeDisabled - Maintenance notifications disabled
  • ModeEnabled - Forcefully enabled (fails if server doesn't support)
  • ModeAuto - Auto-detect server support (default)

Configuration

&maintnotifications.Config{
    Mode:                       maintnotifications.ModeAuto,
    EndpointType:               maintnotifications.EndpointTypeAuto,
    RelaxedTimeout:             10 * time.Second,
    HandoffTimeout:             15 * time.Second,
    MaxHandoffRetries:          3,
    MaxWorkers:                 0,    // Auto-calculated
    HandoffQueueSize:           0,    // Auto-calculated
    PostHandoffRelaxedDuration: 0,    // 2 * RelaxedTimeout
}

Endpoint Types

  • EndpointTypeAuto - Auto-detect based on connection (default)
  • EndpointTypeInternalIP - Internal IP address
  • EndpointTypeInternalFQDN - Internal FQDN
  • EndpointTypeExternalIP - External IP address
  • EndpointTypeExternalFQDN - External FQDN
  • EndpointTypeNone - No endpoint (reconnect with current config)

Auto-Scaling

Workers: min(PoolSize/2, max(10, PoolSize/3)) when auto-calculated Queue: max(20×Workers, PoolSize) capped by MaxActiveConns+1 or 5×PoolSize

Examples:

  • Pool 100: 33 workers, 660 queue (capped at 500)
  • Pool 100 + MaxActiveConns 150: 33 workers, 151 queue

How It Works

  1. KV sends push notifications about cluster maintenance operations
  2. Client creates new connections to updated endpoints
  3. Active operations transfer to new connections
  4. Old connections close gracefully

For more information, see FEATURES