Sidekiq: unknown command 'client' (Redis::CommandError) after 5.0.3 upgrade.

[mattk42]

Ruby version: ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]
Sidekiq version : 5.0.3

We have run into issues listing queues on our sidekiq instances after upgrading to 5.0.3. Rolling back to 5.0.2 fixes this issue. A simple reproduction case below along with the exception.

test.rb

require 'sidekiq'
require 'sidekiq/api'

Sidekiq.configure_client do |sconfig|
  sconfig.redis = { url: "[REDACTED]" }
end

Sidekiq::Queue.all

output with 5.0.3

 # /opt/sensu/embedded/bin/ruby test.rb
/opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:121:in `call': ERR unknown command 'client' (Redis::CommandError)
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:104:in `block in connect'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:293:in `with_reconnect'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:100:in `connect'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:364:in `ensure_connected'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:221:in `block in process'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:306:in `logging'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:220:in `process'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:120:in `call'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis.rb:1398:in `block in smembers'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis.rb:58:in `block in synchronize'
    from /opt/sensu/embedded/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis.rb:58:in `synchronize'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/redis-3.3.3/lib/redis.rb:1397:in `smembers'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sidekiq-5.0.3/lib/sidekiq/api.rb:207:in `block in all'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sidekiq-5.0.3/lib/sidekiq.rb:95:in `block in redis'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/connection_pool-2.2.1/lib/connection_pool.rb:64:in `block (2 levels) in with'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/connection_pool-2.2.1/lib/connection_pool.rb:63:in `handle_interrupt'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/connection_pool-2.2.1/lib/connection_pool.rb:63:in `block in with'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/connection_pool-2.2.1/lib/connection_pool.rb:60:in `handle_interrupt'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/connection_pool-2.2.1/lib/connection_pool.rb:60:in `with'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sidekiq-5.0.3/lib/sidekiq.rb:92:in `redis'
    from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sidekiq-5.0.3/lib/sidekiq/api.rb:207:in `all'
    from test.rb:8:in `<main>'

[mperham]

Could you show me the output of redis-cli info?

[mperham]

I'm thinking you might be using Redis < 2.6.9.

[mattk42]

Sorry for the false alarm. I do have a version of redis that includes the client command but it is currently blocked by the provider of my redis instance. Checking locally I can verify that this is not a problem in a traditional set up.

[vassilevsky]

It's hard to believe, but it looks like a bug in the Redis gem.

irb(main):006:0> redis = Redis.new(host: 'redacted', port: 6379, db: 2)
=> #<Redis client v3.3.3 for redis://redacted:6379/2>
irb(main):007:0> redis_id = Redis.new(host: 'redacted', port: 6379, db: 2, id: 'trololo')
=> #<Redis client v3.3.3 for trololo>
irb(main):008:0> redis.set('a', 1)
=> "OK"
irb(main):009:0> redis_id.set('a', 1)
Redis::CommandError: ERR unknown command 'client'
    from (irb):9
irb(main):010:0> redis.info['redis_version']
=> "3.2.8"

[mperham]

@vassilevsky You're right and the ID situation is really messed up there. You can pass in :id but id is also a method on client that gives you the server location. Sounds like the Redis client needs to change the :id symbol to :name or something like that.

[vassilevsky]

I was wrong. The server really doesn't allow this command.

[vassilevsky]

If you know the renamed CLIENT command, you can remap it:

https://github.com/redis/redis-rb/pull/586#issuecomment-310629204

[taxpon]

I am trying to run sidekiq on GKE along with Google Cloud Memorystore (Full-managed redis service). But it turned out that Memorystroe prohibits CLIENT command execution. Does it mean that I can not run redis with Memorystore or is there any workaround to avoid this error?

[vassilevsky]

Set id: nil in Sidekiq options:

Sidekiq.configure_server do |config|
  config.redis = { url: 'redis://redis.example.com:7372/12', id: nil }
end

Sidekiq.configure_client do |config|
  config.redis = { url: 'redis://redis.example.com:7372/12', id: nil }
end

After that Sidekiq will not issue CLIENT command and it will work.

[vassilevsky]

I have added this information to https://github.com/mperham/sidekiq/wiki/Using-Redis

[taxpon]

@vassilevsky Very thanks for your quick reply! I will follow your instruction.

[ndbroadbent]

Hello, sorry to comment on an old issue. I have been successfully using the workaround in this comment for a while (id: nil). I decided to wrap it in a if ENV['REDIS_DISABLE_CLIENT'].present? condition, so that any of my customers using Redis on Google Cloud could set REDIS_DISABLE_CLIENT=true.

I recently ran into this again. Instead of advising people to set REDIS_DISABLE_CLIENT=true after they run into a crash, I was wondering if there is any downside or danger to just doing this by default? Are there any situations where it's better to use the CLIENT command when possible? Or if the Redis instance is only being used for Sidekiq jobs, then maybe this doesn't matter? Thanks!

[mperham]

I'm suggesting we disable this feature, it's not worth the trouble. You can comment at #4479.