Version 1.3.1 error

[ticktricktrack]

Everything works fine for me when using 1.3.0, but after an auto update to 1.3.1 I got tons of failures.

NoMethodError: undefined method `is_a?' for #<Redis::Future:0x007ffc73bd7c08>
from /Users/rainer/.rvm/gems/ruby-1.9.3-p392@mill33/gems/redis-namespace-1.3.1/lib/redis/namespace.rb:320:in `method_missing'

cat Gemfile.lock | grep redis
      em-hiredis (~> 0.1.0)
    em-hiredis (0.1.1)
      hiredis (~> 0.4.0)
    hiredis (0.4.5)
    redis (3.0.2)
    redis-namespace (1.3.1)
      redis (~> 3.0.0)
      redis-namespace (~> 1.0)
      redis (>= 2.0.1)
  redis (= 3.0.2)

[steveklabnik]

Uh oh! I didn't change anything related to this, are you sure it's the only thing you've changed?

On Mon, Aug 5, 2013 at 12:50 PM, Rainer Kuhn notifications@github.com
wrote:

Everything works fine for me when using 1.3.0, but after an auto update to 1.3.1 I got tons of failures.

NoMethodError: undefined method `is_a?' for #<Redis::Future:0x007ffc73bd7c08>
from /Users/rainer/.rvm/gems/ruby-1.9.3-p392@mill33/gems/redis-namespace-1.3.1/lib/redis/namespace.rb:320:in `method_missing'
cat Gemfile.lock | grep redis
      em-hiredis (~> 0.1.0)
    em-hiredis (0.1.1)
      hiredis (~> 0.4.0)
    hiredis (0.4.5)
    redis (3.0.2)
    redis-namespace (1.3.1)
      redis (~> 3.0.0)
      redis-namespace (~> 1.0)
      redis (>= 2.0.1)
  redis (= 3.0.2)

---

Reply to this email directly or view it on GitHub:
#65

[ticktricktrack]

Yes after a couple of hours of debugging I compared the gem versions between local, staging and production and localized the issue here.
There seems to be a big problem queuing jobs, but for some reason not in all cases. I'm right now deploying the downgrade to 1.3.0 and testing it on production, after that I can go into more debugging on the redis side of things.

[steveklabnik]

Okay. I'll give this a close until we can prove it's an issue.

If you're not using send to a Namespace instance, the security issue isn't an issue for you.

[ticktricktrack]

Ok, I have narrowed things down to a conflict between resque-loner and redis-namespace 1.3.1 and resque 1.23.0
Either upgrading resque or downgrading namespace "fixes" the problem. Since I would have to run more extensive tests on a resque update, I went with the downgrade for now.

I'm educating myself right now on how futures work, but with that gem combo, the result in the namespace method missing isn't a valid ruby object.

Minmized example, run Resque.enqueue(Dummy) in console

https://github.com/ticktricktrack/resque_loner_namespace_conflict

Issue on loner: resque/resque-loner#30
I'm not sure Loner is still being maintained, for the time being I have a fix, but the underlying issue might not solved.

[steveklabnik]

Interesting, thanks! re-opening until we can get to the bottom of this.

I'm not sure either, I opened an issue 5 months ago and haven't heard back.

[ticktricktrack]

Let me know how I can help here, I'm also not sure how rare this gem version combo is, might be the only one here.

I used pry withing method_missing to debug, but that didn't get me far, except knowing that its not a valid ruby object. I'm still trying to figure out how loner actually changes the behaviour.

[guitsaru]

I ran in to the same issue today and it looks like it's actually a problem with the redis gem. Upgrading to redis 3.0.4 fixes the issue.

→ irb
>> require 'redis-namespace'
=> true
>> redis = Redis::Namespace.new(:test, redis: Redis.new)
=> #<Redis::Namespace:0x007ffc21931ca8 @namespace=:test, @redis=#<Redis client v3.0.2 for redis://127.0.0.1:6379/0>, @warning=false>
>> redis.multi do
?>     redis.set "foo", "bar"
>>   end
NoMethodError: undefined method `is_a?' for <Redis::Future [:set, "test:foo", "bar"]>:Redis::Future
    from /Users/mattpruitt/.gem/ruby/1.9.3/gems/redis-namespace-1.3.1/lib/redis/namespace.rb:320:in `method_missing'
    from (irb):4:in `block in irb_binding'
    from /Users/mattpruitt/.gem/ruby/1.9.3/gems/redis-namespace-1.3.1/lib/redis/namespace.rb:339:in `block in namespaced_block'
    from /Users/mattpruitt/.gem/ruby/1.9.3/gems/redis-3.0.2/lib/redis.rb:2019:in `block in multi'
    from /Users/mattpruitt/.gem/ruby/1.9.3/gems/redis-3.0.2/lib/redis.rb:36:in `block in synchronize'
    from /Users/mattpruitt/.rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
    from /Users/mattpruitt/.gem/ruby/1.9.3/gems/redis-3.0.2/lib/redis.rb:36:in `synchronize'
    from /Users/mattpruitt/.gem/ruby/1.9.3/gems/redis-3.0.2/lib/redis.rb:2012:in `multi'
    from /Users/mattpruitt/.gem/ruby/1.9.3/gems/redis-namespace-1.3.1/lib/redis/namespace.rb:337:in `namespaced_block'
    from /Users/mattpruitt/.gem/ruby/1.9.3/gems/redis-namespace-1.3.1/lib/redis/namespace.rb:224:in `multi'
    from (irb):3
    from /Users/mattpruitt/.rubies/ruby-1.9.3-p448/bin/irb:12:in `<main>'
>> exit
→ gem list redis

*** LOCAL GEMS ***

redis (3.0.2)
redis-namespace (1.3.1)
→ gem install redis
Fetching: redis-3.0.4.gem (100%)
Successfully installed redis-3.0.4
1 gem installed
→ irb
>> require 'redis-namespace'
=> true
>> redis = Redis::Namespace.new(:test, redis: Redis.new)
=> #<Redis::Namespace:0x007faecb984e60 @namespace=:test, @redis=#<Redis client v3.0.4 for redis://127.0.0.1:6379/0>, @warning=false>
>> redis.multi do
?>     redis.set "foo", "bar"
>>   end
=> ["OK"]
>> exit

[hli]

5d21434
needed
redis/redis-rb@f7bfcbd

[steveklabnik]

Ahh, I wasn't aware :/

[ticktricktrack]

Awesome guys, thanks!

[yaauie]

The fix has been released is in redis-namespace-1.3.2.