chore(deps): bump ioredis to 6.0.0 and pin the RESP2 wire protocol - #241
Merged
Conversation
ioredis 6 negotiates RESP3 by default and requires Node 20+. The engine requirement is already satisfied (>=22), but the protocol switch is not covered by CI: the Redis client is fully mocked in the unit tests, and the CI service runs the default user on localhost, while production connects as an ACL user over an authenticated URL. That combination is the problem. getRedis() is deliberately fail-open, so a handshake that the server rejects would not surface as an error page or a crash. Rate limiting on the public submit endpoint would simply stop applying, leaving only a log line behind. Set protocol: 2 to keep the v5 wire format. The only consumer is the fixed window EVAL in the rate limiter, which gains nothing from RESP3, so there is no reason to take that risk as a side effect of a version bump. RESP3 can be adopted later as its own change, verified against the live server. Supersedes #238, which bumps the same dependency without the pin.
Musiker15
force-pushed
the
chore/ioredis-6-resp2
branch
from
August 17, 2026 21:16
620f698 to
ed4e7ef
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps
ioredisfrom 5.11.1 to 6.0.0 and setsprotocol: 2on the client.Why not just merge #238
ioredis 6 has two breaking changes: it requires Node 20+ and it negotiates RESP3 by default. The engine requirement is already met (
>=22), the protocol switch is the open question.CI cannot answer it:
apps/web/src/lib/rate-limit.test.tsmocksgetRedisentirely, so no test ever opens a connection.redis:7onredis://localhost:6379, the default user without ACL or password. Production connects as the ACL usermsk_formsover an authenticated URL.So a green run on #238 proves the bump typechecks and builds, nothing more.
The failure mode is what makes that uncomfortable.
getRedis()is deliberately fail-open andrateLimit()swallows command errors, which is right for availability. It also means a rejected handshake produces no error page and no crash. Rate limiting on the public submit endpoint would quietly stop applying and leave a single log line.What this does instead
protocol: 2keeps the v5 wire format, so the bump carries no protocol change. The only consumer is the fixed-windowEVALin the rate limiter, which gains nothing from RESP3.RESP3 is worth adopting, but as its own change with a check against the live server, not as a side effect of a version bump.
Verification
lint,typecheck,testandbuildpass locally. The typecheck also confirmsprotocolis a real option in the v6 types.Worth a look after deploy: hit a public form twice in quick succession and confirm the 429 still fires, or check
redis-cli -u "$REDIS_URL" --scan --pattern 'rl:*'for live keys.