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.
KV lives in its own org now, like hanzokms / hanzos3 / hanzo-ds. The repo moved
hanzoai/kv-go -> hanzokv/go, so the module path follows: a Go module path must
match where the repo actually is, or the proxy cannot resolve it.
The name is `go`, not `kv-go`, following the hanzo-ds convention — that org
holds go, mock, native, sqlbuilder, sqlparser, each named for its language or
concern with the ORG supplying the product noun. Repeating "kv" inside a repo
that already lives under hanzokv is the compound-word habit we are dropping.
349 occurrences across 188 files: the root module, all four extra/* modules,
every example module, imports throughout the tree, and the docs. Builds clean.
The package is still `package redis` and the extra dirs are still named
redis*. That rename is deliberately NOT bundled here: it is 5,771 occurrences,
it breaks all 11 consumers at once, and a large share are WIRE CONTRACTS rather
than branding — the redis:// scheme parser, the "redis: nil" error string, RESP
command names. Renaming those breaks protocol compatibility with the Valkey
server. It needs the same our-vocabulary-vs-the-wire split the argo sweep used,
as its own change.
GitHub keeps the old path redirecting, and versions already published under
github.com/hanzoai/kv-go/v9 stay resolvable, so nothing breaks the moment this
lands. Consumers move on their own schedule.
Update module path from github.com/redis/go-redis/v9 to
github.com/hanzoai/kv-go/v9 for use as the Hanzo KV Go SDK.
- Update go.mod module declaration
- Update all Go imports across 260 files
- Update all submodule go.mod files (extra/*, example/*, internal/customvet)
* fix(pool): wip, pool reauth should not interfere with handoff
* fix credListeners map
* fix race in tests
* better conn usable timeout
* add design decision comment
* few small improvements
* update marked as queued
* add Used to clarify the state of the conn
* rename test
* fix(test): fix flaky test
* lock inside the listeners collection
* address pr comments
* Update internal/auth/cred_listeners.go
Co-authored-by: Copilot <[email protected]>
* Update internal/pool/buffer_size_test.go
Co-authored-by: Copilot <[email protected]>
* wip refactor entraid
* fix maintnotif pool hook
* fix mocks
* fix nil listener
* sync and async reauth based on conn lifecycle
* be able to reject connection OnGet
* pass hooks so the tests can observe reauth
* give some time for the background to execute commands
* fix tests
* only async reauth
* Update internal/pool/pool.go
Co-authored-by: Copilot <[email protected]>
* Update internal/auth/streaming/pool_hook.go
Co-authored-by: Copilot <[email protected]>
* Update internal/pool/conn.go
Co-authored-by: Copilot <[email protected]>
* chore(redisotel): use metric.WithAttributeSet to avoid copy (#3552)
In order to improve performance replace `WithAttributes` with `WithAttributeSet`.
This avoids the slice allocation and copy that is done in `WithAttributes`.
For more information see https://github.com/open-telemetry/opentelemetry-go/blob/v1.38.0/metric/instrument.go#L357-L376
* chore(docs): explain why MaxRetries is disabled for ClusterClient (#3551)
Co-authored-by: Nedyalko Dyakov <[email protected]>
* exponential backoff
* address pr comments
* address pr comments
* remove rlock
* add some comments
* add comments
---------
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Warnar Boekkooi <[email protected]>
Co-authored-by: Justin <[email protected]>
* fix(txpipeline): should return error on multi/exec on multiple slots
* fix(txpipeline): test normal tx pipeline behaviour
* chore(err): Extract crossslot err and add test
* fix(txpipeline): short curcuit the tx if there are no commands
* chore(tests): validate keys are in different slots
When clusters are running with `replica-server-stale-data no`, replicas
will return a MASTERDOWN error under two conditions:
1. The primary has failed and we are not serving requests.
2. A replica has just started and has not yet synced from the primary.
The former, primary has failed and we are not serving requests, is
similar to a CLUSTERDOWN error and should be similarly retriable.
When a replica has just started and has not yet synced from the primary
the request should be retried on other available nodes in the shard.
Otherwise a percentage of the read requests to the shard will fail.
Examples when `replica-server-stale-data no` is enabled:
1. In a cluster using `ReadOnly` with a single read replica, every
read request will return errors to the client because MASTERDOWN is
not a retriable error.
2. In a cluster using `RouteRandomly` a percentage of the requests
will return errors to the client based on if this server was
selected.
Co-authored-by: Nedyalko Dyakov <[email protected]>
* fix: recycle connections in some Redis Cluster scenarios
This issue was surfaced in a Cloud Provider solution that used for
rolling out new nodes using the same address (hostname) of the nodes
that will be replaced in a Redis Cluster, while the former ones once
depromoted as Slaves would continue in service during some mintues
for redirecting traffic.
The solution basically identifies when the connection could be stale
since a MOVED response will be returned using the same address (hostname)
that is being used by the connection. At that moment we consider the
connection as no longer usable forcing to recycle the connection.
zeekay
