🔧 fix(redis): Resolve Redis Standalone vs Cluster mode discrepancy for social logins

[arthurian]

Summary

Resolves an issue with OpenID authentication requests hanging and timing out when using Redis in Standalone mode (see also #2843).

Steps to reproduce:

• Set up a Standalone Redis server.
• Set the USE_REDIS and REDIS_URI env vars.
• Set the ALLOW_SOCIAL_LOGIN and OPENID_* env vars.
• Navigate to login page.
• Click Continue with OpenID.
• Request times out.

This issue can be traced to the way social logins are configured at startup, since a RedisStore is configured for session storage with the client from api/cache/redis.js, but this client assumes that Redis is running in Cluster mode, and as a result it fails to connect (times out). The connection error is silently ignored, so it doesn't show up in the log output. By contrast, the api/cache/keyvRedis.js client successfully connects to Redis in Standalone mode and reports Redis initialized.

As it stands, neither redis.js nor keyvRedis.js support Cluster mode and doing so would require introducing additional configuration and logic, so the proposed fix is to resolve the immediate discrepancy to ensure that both work with Redis in Standalone mode. The suggestions proposed in #2843 to support Cluster mode could be considered for a subsequent enhancement.

Change Type

• Bug fix (non-breaking change which fixes an issue)

Testing

Test Configuration:

I have confirmed that the proposed updates work with an AWS ElasticCache Redis installation running in Standalone mode. There's no additional configuration required to test this besides setting the environment variables to use redis and OpenID authentication.

Test Script:

The following script adapted from api/cache/redis.js can be used to show the problem when REDIS_URI points to a Standalone installation:

const Redis = require('ioredis');
const { REDIS_URI } = process.env; 

const redisCluster = new Redis.Cluster(REDIS_URI, { lazyConnect: true });
redisCluster.connect()
  .then(() => console.log('redis cluster initialized'))
  .catch((err) => console.error(`redis cluster error: ${err}`));

const redisStandalone = new Redis(REDIS_URI, { lazyConnect: true });
redisStandalone.connect()
  .then(() => console.log('redis standalone initialized'))
  .catch((err) => console.error(`redis standalone error: ${err}`));

The following output is expected when running the script:

redis cluster error: Error: `startupNodes` should contain at least one node.
redis standalone initialized

Checklist

• My code adheres to this project's style guidelines
• I have performed a self-review of my own code
• My changes do not introduce new warnings
• Local unit tests pass with my changes

[danny-avila]

Thank you!

[danny-avila]

Unfortunately just noticed there are elevated errors when Redis is not configured:

The session caching is initialized like this: api/server/socialLogins.js

sessionOptions.store = new RedisStore({ client, prefix: 'librechat' });

Seems to be attempting connection even when it's not configured?

[arthurian]

Ah yes, you're right. That's my fault -- the event handlers should be added only if USE_REDIS is enabled in api/cache/redis.js.

[danny-avila]

@arthurian I reverted the changes and adding this to prevent wall of errors, let me know if this change works for you. This might be the most optimal solution if it does. It makes sense to use different clients for separate purposes

[danny-avila]

Actually made an error, here is the updated commit: 0f42793

[arthurian]

Yeah, that would work for us. The only addendum I would suggest is to make sure the Redis standalone client is passed in to RedisStore, so change:

new RedisStore({ client, prefix: 'librechat' });

To:

new RedisStore({ client: redis, prefix: 'librechat' });

[arthurian]

Actually nvm, I saw in your updated commit 0f42793 you renamed redis to client.