Bump redis from 4.7.1 to 6.2.0 - #708
Conversation
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
7529fca to
e962c0d
Compare
…cted to one Dependabot's redis 4 -> 6 (#708) is two majors on the library behind src/cache.js and src/shared-limit.js, and its CI was green. That green was worth nothing: no workflow ran a redis, and test-shared-limit.js injects a fake store on purpose - it proves "two callers share one counter", and a fake proves that exactly - so the CLIENT path was never exercised. createClient options, connect, command shapes, quit: all untested. Same worthless green as the tesseract 5 -> 7 trap, which passed 210 assertions while silently emptying a paid tool's output. It matters because prod is NOT in-memory. Verified against Railway rather than against notes: REDIS_URL and RATE_LIMIT_REPLICAS are both set on the production service and the project runs a dedicated Redis. The shared limiter FAILS CLOSED, so a client regression refuses trials rather than degrading quietly. The memory note claiming "prod is in-memory, low risk, take anytime" was wrong in the reassuring direction and would have merged the bump. So: a redis service container on the test job, and an integration test that drives the real client - cap-of-1 across callers, the over-limit decrement, refund flooring, and a cache set/get round trip. It asserts degraded === false, because the fail-closed path would otherwise let every assertion pass for the wrong reason with no server at all. It REQUIRES a server and exits 1 without one. It does not skip: a skipped integration test is precisely why this went untested, and "no redis in CI" means the service container is gone, which is the regression this guards. Caught while writing it: peek() returns { limited, count, degraded }, not `.used` as I had assumed - read the source instead of guessing, since a wrong assertion here would have looked like a redis failure. NOT verified locally (no redis or docker on this machine), so CI is the first real run. Flagged rather than glossed. This makes #708 decidable instead of a coin flip. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Holding this until it can be decided on evidence rather than a green badge. As of #714 the test job runs a real This matters because production is not in-memory: @dependabot rebase — so this PR picks up the new coverage and its CI actually exercises redis 6. |
Bumps [redis](https://github.com/redis/node-redis) from 4.7.1 to 6.2.0. - [Release notes](https://github.com/redis/node-redis/releases) - [Changelog](https://github.com/redis/node-redis/blob/master/CHANGELOG.md) - [Commits](https://github.com/redis/node-redis/compare/redis@4.7.1...redis@6.2.0) --- updated-dependencies: - dependency-name: redis dependency-version: 6.2.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
e962c0d to
ae1b211
Compare
MikeyPetrillo
left a comment
MikeyPetrillo
left a comment
There was a problem hiding this comment.
Reviewed: redis 4.7.1→6.2.0 is API-compatible with our createClient/connect/incr/get/set usage. Real redis CI (test-redis-integration.js) passed 11/11 after rebase. Not on the settlement path; shared-limit stays fail-closed. Safe to merge as maintenance.
1 participant
Bumps redis from 4.7.1 to 6.2.0.
Release notes
Sourced from redis's releases.
... (truncated)
Commits
b48e0d3Release redis@6.2.023b33edRelease entraid@6.2.071b820bRelease time-series@6.2.02dde5dfRelease search@6.2.06164fd6Release json@6.2.079521a5Release bloom@6.2.022fbee6Release client@6.2.0f2a432fRequest response policies (#2996)043d304feat: add COMMAND DOCS support (#3362)87623a6fix(client): include acquire timeout duration in pool timeout error message (...