chore(deps): bump redis/go-redis/v9 9.21.0 → 9.22.0 (+ mock regen)

[Umang01-hash]

redis/go-redis/v9 9.21.0 → 9.22.0

Split out of the minor/patch consolidation (#4048) because it needs a generated-source change, not just manifests.

Why the mock changes

go-redis 9.22.0 adds new methods to redis.Cmdable (BLMoveM, LMoveM, ClientTracking*, HImport*, InfoMap, SDiffCard, SUnionCard, and the TS* time-series calls). GoFr's container.Redis interface embeds redis.Cmdable, so the generated MockRedis stops satisfying the interface until regenerated — the build fails with *MockRedis does not implement Redis (missing method BLMoveM) otherwise.

Changes

• go.mod / go.sum: github.com/redis/go-redis/v9 9.21.0 → 9.22.0.
• pkg/gofr/container/mock_datasources.go: regenerated via go generate (go.uber.org/mock/mockgen -source=datasources.go). Diff is pure additions (319 insertions, 0 deletions) — only the new Cmdable methods.

Verification

• ✅ go build ./... green on root + all 26 pkg/ library modules.
• ✅ All pkg/ submodules pass go mod tidy -diff (CI tidiness gate).
• ✅ Mock diff is generated output only — no hand edits, no removals.

Closes #3987

🤖 Generated with claude-flow

[aryanmehrotra]

Approving — splitting this out of #4048 was the right call, and the regeneration is sound. But there
is a behaviour change riding along that isn't in the description and should reach the release notes.

What I verified

The mock is genuinely generated, not hand-edited. I re-ran it myself:

go run go.uber.org/mock/mockgen -source=datasources.go -destination=mock_datasources.go -package=container

and the committed file is byte-identical to the output. The +319/-0 is itself good evidence:
a purely additive regenerated mock proves redis.Cmdable only gained methods and changed none.

Also checked, since a go.work workspace makes version skew easy to miss:

• Root module builds; pkg/gofr/container and pkg/gofr/datasource/redis tests pass; root
  go.mod/go.sum stay tidy.
• redisotel and rediscmd stay at 9.21.0 against go-redis 9.22.0 — they compile fine, the Hook
  interface is unchanged.
• Standalone submodule builds are unaffected: they require published gofr.dev v1.57.0 rather than
  replacing to the local tree, so they keep resolving 9.21.0 until the next release.
• The WaitAOF return-type change upstream flags as breaking does not apply to us — it is a
  method on the concrete cmdable struct and is not declared in the Cmdable interface we embed.
  That is also why the regenerated mock shows zero deletions.

The part that needs recording

The 9.22.0 notes flag a second upgrade concern: "Default configuration values changed (#3918) …
Explicitly configured values are unaffected."

We do not configure them. pkg/gofr/datasource/redis/config.go:62-77 sets only Addr, Username,
Password, DB and optionally TLSConfig, so we inherit every default:

default	9.21.0	9.22.0
ReadTimeout	3s	5s
WriteTimeout	follows ReadTimeout, 3s	follows ReadTimeout, 5s
MinRetryBackoff	8ms	10ms
DialTimeout	5s	unchanged
MaxRetries	3	unchanged

So after this merges, a handler hitting a stalled Redis blocks 5s instead of 3s before erroring —
a 67% increase in worst-case latency on that path. It compiles, it tests green, and it surfaces only
as requests breaching an upstream timeout in production.

There is no escape hatch either: the config surface is REDIS_HOST/PORT/USER/PASSWORD/DB/TLS_*/ PUBSUB_*/STREAMS_*, with no REDIS_READ_TIMEOUT or equivalent, so an application cannot override it.

Nothing here changes the verdict — the bump is right and holding it helps nobody. Two asks:

1. Add the timeout change to the release notes for whichever version carries this.
2. Worth exposing these as REDIS_* config in their own change, so the defaults stop being something
   we inherit silently on every go-redis bump. Happy to file that separately.