Skip to content

💥 Bump redis version to 5.0.0 #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
May 20, 2025
Merged

💥 Bump redis version to 5.0.0 #24

merged 6 commits into from
May 20, 2025

Conversation

dawidreedsy
Copy link
Contributor

@dawidreedsy dawidreedsy commented May 19, 2025

Redis released version 5 , but the only breaking change that is affecting us is:

Connection Management:

client.QUIT/quit() is replaced by client.close()
client.disconnect() has been renamed to client.destroy()

I tried to make it a non breakable change, by allowing both close and quit

@dawidreedsy dawidreedsy force-pushed the bump-redis-version branch 2 times, most recently from 833c18f to e1d6a62 Compare May 19, 2025 14:02
Redis released [version 5](https://github.com/redis/node-redis/releases/tag/redis%405.0.0) , but the only breaking change that is affecting us is:

```
Connection Management:

client.QUIT/quit() is replaced by client.close()
client.disconnect() has been renamed to client.destroy()
```

I tried to make it a non breakable change, by allowing both close and quit
@dawidreedsy dawidreedsy force-pushed the bump-redis-version branch from e1d6a62 to 7f1b1ed Compare May 19, 2025 14:02
@dawidreedsy
Copy link
Contributor Author

dawidreedsy commented May 19, 2025

It looks like now redis is waiting for all the pending commands to finish then only destroys the socket:
https://github.com/redis/node-redis/blob/47e297077a20f396a1b22fafa917cea284dc3427/packages/client/lib/client/index.ts#L1198-L1219

Not yet sure what command is pending in tests though. This is the command from the wait queue

{
  args: undefined,
  chainId: undefined,
  abort: undefined,
  resolve: [Function: resolve],
  reject: [Function: reject],
  channelsCounter: 1,
  typeMapping: {
    '36': [Function: Buffer] {
      poolSize: 8192,
      from: [Function: from],
      copyBytesFrom: [Function: copyBytesFrom],
      of: [Function: of],
      alloc: [Function: alloc],
      allocUnsafe: [Function: allocUnsafe],
      allocUnsafeSlow: [Function: allocUnsafeSlow],
      isBuffer: [Function: isBuffer],
      compare: [Function: compare],
      isEncoding: [Function: isEncoding],
      concat: [Function: concat],
      byteLength: [Function: byteLength],
      [Symbol(kIsEncodingSymbol)]: [Function: isEncoding]
    }
  }
}

The weird part here is that args is undefined,

It might be relatred to publish command though

sendCommand [
  'EVAL',
  'for i = 2, #ARGV do redis.call("publish", ARGV[i], ARGV[1]) end',
  '0',
  '{"test":true}',
  'x',
  'y'
]

index.js Outdated
Comment on lines 46 to 47
close(this.client),
close(this.observer)
Copy link
Contributor

Choose a reason for hiding this comment

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

The issue here is that there's a bug where we're eagerly calling close() (which to be fair existed before 🙈 ), since the contents of Promise.all() are immediately invoked because we're missing a closure inside .then(). I think this function should read:

RedisPubSub.prototype._close = function() {
  var pubsub = this;
  return this._closing = this._closing || this._connect().then(function() {
    return Promise.all([
      close(pubsub.client),
      close(pubsub.observer)
    ]);
  });
};

I tried this locally and it seems to solve the socket hangup issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thats a good spot!

@@ -92,3 +92,11 @@ var PUBLISH_SCRIPT =
'for i = 2, #ARGV do ' +
'redis.call("publish", ARGV[i], ARGV[1]) ' +
'end';

function close(client) {
if (client.close) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think technically .quit() is only deprecated for Redis server >=7.2:

As of Redis version 7.2.0, this command is regarded as deprecated.

It can be replaced by just closing the connection when migrating or writing new code.

I think I'd read this notice as anyone using Redis server <7.2 should still use .quit(), regardless of Node.js client version(?).

Not sure how we want to handle this?

Copy link
Contributor Author

@dawidreedsy dawidreedsy May 20, 2025

Choose a reason for hiding this comment

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

This is the note in the Redis docs:

Note: Clients should not use this command. Instead, clients should simply close the connection when they're not used anymore. Terminating a connection on the client side is preferable, as it eliminates TIME_WAIT lingering sockets on the server side.

The redis-node code does seem to just close the socket connection. I guess it is the same thing as closing connection to internet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@alecgibson @ericyhwang
This is a breaking change anyway:

Maybe we can just drop support for node-redis < 5.0.0 then we can just use close.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay turns out redis@5 doesn't support Redis server <7.2, so I guess it doesn't matter if older server users should still use .quit(), because those consumers should still be on redis@4.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we shouldn't make this change breaking. It's nice to let people use the older version if possible, especially because it makes the migration path easier to keep the shim around. And since it's super easy for us, I don't see why not.

package.json Outdated
@@ -1,10 +1,10 @@
{
"name": "sharedb-redis-pubsub",
"version": "5.0.1",
"version": "5.0.2",
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd consider this a minor patch given that it adds functionality

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Change to 5.1.0

Comment on lines 21 to 22
- 22
- 24
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's deal with Node.js versions separately please. eg I think 16 is EOL, and we should consider that change separately (as a major bump)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed

@coveralls
Copy link

coveralls commented May 20, 2025

Coverage Status

coverage: 100.0%. remained the same
when pulling abc1d92 on bump-redis-version
into 819b549 on master.

@dawidreedsy dawidreedsy merged commit 063504d into master May 20, 2025
22 of 25 checks passed
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.

4 participants