Skip to content

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

Merged
Umang01-hash merged 2 commits into
developmentfrom
deps/redis-v9.22-2026-08-21
Aug 25, 2026
Merged

chore(deps): bump redis/go-redis/v9 9.21.0 → 9.22.0 (+ mock regen)#4051
Umang01-hash merged 2 commits into
developmentfrom
deps/redis-v9.22-2026-08-21

Conversation

@Umang01-hash

Copy link
Copy Markdown
Member

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

go-redis 9.22.0 adds new methods to redis.Cmdable (BLMoveM, LMoveM,
ClientTracking*, HImport*, InfoMap, SDiffCard, SUnionCard, TS* time-series,
etc.). GoFr's container.Redis interface embeds redis.Cmdable, so MockRedis no
longer satisfies it until regenerated.

- go.mod/go.sum: 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). Pure additions (0 deletions) — the new Cmdable
  methods only.

Separated from the minor/patch consolidation (#4048) because it requires this
generated-source change. 'go build ./...' green on root + all pkg/ modules;
all pkg/ submodules pass 'go mod tidy -diff'.

Closes: #3987

Co-Authored-By: claude-flow <ruv@ruv.net>

@aryanmehrotra aryanmehrotra left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Umang01-hash
Umang01-hash merged commit a0dbf76 into development Aug 25, 2026
19 checks passed
@Umang01-hash
Umang01-hash deleted the deps/redis-v9.22-2026-08-21 branch August 25, 2026 04:50
aryanmehrotra added a commit that referenced this pull request Aug 31, 2026
* Merge pull request #3815 from akshat-kumar-singhal/fix/flaky-cron-nil-logger-sql-mock-3813

fix(cron): join in-flight jobs on Stop and skip jobs with no logger

* chore(ci): pin ls-lint/action to node24 commit to clear Node 20 warning (#3864)

v2.3.1 declares `using: node20`, so every Linting Party run emits the
Node.js 20 deprecation warning. Upstream fixed it in 0c7f19c ("chore: run
on the node24 runtime"), but no release carries it yet, so pin the SHA.
Revert to a tag once ls-lint cuts a release with the node24 runtime.

Co-authored-by: Aryan Mehrotra <aryanmehrotra2000@gmail.com>

* fix(grpc): guard the server handle so Run and Shutdown stop racing (#3929) (#3931)

* chore(ci): build the website workflows on Node 24 instead of EOL Node 18 (#3870) (#3871)

Node 18 "Hydrogen" reached end-of-life on 2025-04-30 and receives no
security patches, including for the bundled OpenSSL and undici. The
prod and stage website workflows build and deploy gofr.dev — they run
`yarn install --frozen-lockfile` and `yarn refresh-data` against the
network while holding the GAR deployment key and `packages: write`.

Targets 24.x rather than the 22.x the issue suggested: v22 has been in
maintenance since 2025-10-21 while v24 is the Active LTS through
2028-04-30. Verified `yarn install --frozen-lockfile` is green on
node:24-alpine against the website's current lockfile.

Both files changed together so prod and stage don't drift.

Co-authored-by: Aryan Mehrotra <aryanmehrotra2000@gmail.com>

* fix(examples): wait on a readiness signal instead of sleeping, and make using-migrations self-contained (#3818, #3816) (#3821)

* feat(ai): add Embed capability to the LLM (#3757)

* perf(http): opt-in O(1) trie router behind GOFR_ROUTER (#3759)

* chore(deps): consolidate minor/patch dependency updates (2026-08-18) (#3969)

* fix(ci): wait for Example-Unit-Testing services to be ready, and pin Zipkin (#3868) (#3939)

* chore(ci): add concurrency groups and job timeouts, pin actions by SHA (#3865, #3867) (#3936)

* fix(ci): stop mutating go.mod mid-run; check submodule tidiness without writing (#3869) (#3938)

* chore(deps): close the dependabot coverage gaps and retire EOL base images (#3873) (#3937)

* chore(deps): bump tj-actions/changed-files 47.0.0 -> 47.0.6 (#4049)

* chore(deps): bump redis/go-redis/v9 9.21.0 -> 9.22.0 + regenerate mock (#4051)

* chore(deps): bump golang 1.26-alpine -> 1.27-alpine in examples/http-server (#4098)

Docker base image bump from Dependabot #4064 (docker group).

Closes: #4064

Co-authored-by: claude-flow <ruv@ruv.net>

* fix(http): characterize the request path and fix eleven defects it exposed (#3770)

* perf(logging,http): skip request logs the level discards, and co-allocate the request objects (#3974)

* update release version to v1.60.0

* fix(ai): make Embed a method on ai.LLM instead of a type assertion (#4108)

* fix(test): stop pinning the tracer scope name to a development build (#4109)

---------

Co-authored-by: Akshat Singhal <65562230+akshat-kumar-singhal@users.noreply.github.com>
Co-authored-by: Umang Mundhra <mundhraumang.02@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants