mirror of
https://github.com/hanzokv/go.git
synced 2026-09-24 00:31:51 +00:00
zeekay
6994cf05aa
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.
22 lines
1.1 KiB
Go
22 lines
1.1 KiB
Go
// Package e2e provides end-to-end testing scenarios for the maintenance notifications system.
|
|
//
|
|
// This package contains comprehensive test scenarios that validate the maintenance notifications
|
|
// functionality in realistic environments. The tests are designed to work with KV Enterprise
|
|
// clusters and require specific environment configuration.
|
|
//
|
|
// Environment Variables:
|
|
// - E2E_SCENARIO_TESTS: Set to "true" to enable scenario tests
|
|
// - KV_ENDPOINTS_CONFIG_PATH: Path to endpoints configuration file
|
|
// - FAULT_INJECTION_API_URL: URL for fault injection API (optional)
|
|
//
|
|
// Test Scenarios:
|
|
// - Basic Push Notifications: Core functionality testing
|
|
// - Endpoint Types: Different endpoint resolution strategies
|
|
// - Timeout Configurations: Various timeout strategies
|
|
// - TLS Configurations: Different TLS setups
|
|
// - Stress Testing: Extreme load and concurrent operations
|
|
//
|
|
// Note: Maintenance notifications are currently supported only in standalone KV clients.
|
|
// Cluster clients (ClusterClient, FailoverClient, etc.) do not yet support this functionality.
|
|
package e2e
|