Redis resolves the keys it must invalidate in getKeysFromCommand(): the
module getkeys API, then getkeys_proc, then the legacy range. Key specs are
never consulted, so a module command that declares movable keys without
registering a getkeys callback is tracked by its legacy positions alone,
usually none. cscDeriveMeta indexed the spec positions instead, and the
entry then sits stale for its whole life because no invalidation ever
matches it.
Deriving no extraction means the command is never cached, so the guarantee
no longer depends on remembering each module command in a dont_cache
correction. The cacheable-command list is unchanged; the pinned
fingerprint moves because ts.nrange and ts.nrevrange now derive no
extraction.
Refs #4097
Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>
A null attribute (|-1) is not valid RESP3, but ReadAttributeLen consumes
the header and reports proto.Nil. peekCommandInfoReplyType passed that
error on, and the COMMAND readers treat a Nil error as "the value was
already drained", so the wrapped reply stayed on the wire and the
connection went back to the pool out of step with the stream.
Unwrap it as an empty attribute instead.
Refs #4097
Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>
HOTKEYS GET reports the session CPU time as total-cpu-time-user-ms and
total-cpu-time-sys-ms, which is how src/hotkeys.c and the command docs name
them. readReply looked up used-cpu-user-ms and used-cpu-sys-ms instead, so
UsedCPUUser and UsedCPUSys stayed zero for every reply.
* docs(readme): fix the supported-versions list
The Supported versions section lists Redis 8.0, 8.2, 8.4, 8.8 and 8.10, but
that is not what CI builds against. `.github/workflows/build.yml` runs both
`test-stack` (:48-54) and `test-redis-ce` (:109-115) over
8.12.x, 8.10.x, 8.6.x, 8.4.x, 8.2.x and 8.0.x.
So two versions that are tested are missing from the list (8.6, and 8.12 as a
pre-release) while 8.8 is listed although it is no longer exercised — its
removal from the matrix is recorded in RELEASE-NOTES.md:440 ("8.8 was dropped
from the CI matrix", #3940).
Rewrite the list to match the matrix. The "last three releases" sentence is
left as-is: it states the policy, not a fact CI can confirm.
* docs(readme): avoid unknown word in the 8.12 support note
* docs(readme): preserve supported Redis versions
---------
Co-authored-by: ump45nose <ump45nose@users.noreply.github.com>
Both FT.AGGREGATE examples tell the reader to set `UnstableResp3: true` to
use RESP3:
example/search-aggregate-steps/README.md:15-17
example/search-aggregate-collect/README.md:15-18
That advice is stale in two ways. `Options.UnstableResp3` is deprecated and
documented as a no-op (`options.go:448-451`, and the same note on
`universal.go`, `osscluster.go`, `ring.go`, `sentinel.go`); README.md:536-543
says plainly that "new code should not set it". Grepping the package shows the
field is only ever copied between option structs (`universal.go:291`,
`osscluster.go:514`, `ring.go:276`, `sentinel.go:255`) or assigned from a URL
(`sentinel.go:507`) — nothing reads it, so following the advice would change
nothing.
The stated reason is also gone: RediSearch RESP3 parsing has been stable since
v9.20, which is why no flag is needed. The examples still construct their
client with `Protocol: 2` (`search-aggregate-steps/main.go:25`,
`search-aggregate-collect/main.go:29`); that choice is left alone, only the
justification is corrected.
* docs(ts): call the incrby/decrby delta a value
TSIncrBy, TSIncrByWithArgs, TSDecrBy and TSDecrByWithArgs all said the
argument is a timestamp, but it is placed in the addition_value slot of
TS.INCRBY/TS.DECRBY. The real timestamp is passed separately as the TIMESTAMP
option (see TSIncrDecrOptions.Timestamp), which the very same doc comment
lists as an additional option.
* fix(ts): rename incrby/decrby timestamp argument to value
Follow-up to the doc fix: the parameter of TSIncrBy, TSIncrByWithArgs,
TSDecrBy and TSDecrByWithArgs is the addition value, not a timestamp, so
name it value to match the doc comments. No behavior or API change.
The "Look and feel" block documents each snippet with the uppercase Redis
command syntax it stands for ("SET key value EX 10 NX", "SORT list LIMIT
0 2 ASC", "ZRANGEBYSCORE zset -inf +inf WITHSCORES LIMIT 0 2"), but the
KeepTTL snippet alone writes its option in lowercase. Redis spells the SET
option KEEPTTL, so align the comment with the other five uppercase
snippets.
Comment text only; the Go line below is unchanged.
The TSAdd and TSAddWithArgs doc comments said the observations go into a
t-digest sketch, but both build a TS.ADD command that appends one
timestamp/value sample to a time-series key. TSMAdd in the same file already
uses the correct wording.
The "NOTE ... is still experimental" comment on the newer string commands
read "it's signature and behaviour may change", using the contraction
where the possessive determiner is needed. These comments are rendered as
godoc, so the mistake is user-visible on pkg.go.dev.
Only the pronoun changes: wording and line breaks are untouched, and no
code moves.
