monitoring a redis using lua produces Uncaught TypeError: Cannot read property 'callback' of undefined

[bpytlik]

• Version: node_redis 2.6.3 redis 3.0.5
• Platform: Node.js 0.12.16 on linux
• Description:
  I'm observing this error with version 2.6.3. My problem seems to be tied to the monitor command. I've added this comment here since the symptoms are the same, but I'd be happy to open a new issue for this specific problem. I don't currently have a separable code sample as this is being observed in my application's test suite and extracting that is going to be difficult.

Here is the summary of what the test does:

1. start up a redis server
2. create a redis client pointed at that server
3. run monitor on that server
4. exec a program that sends the redis server a BGREWRITEAOF command
5. waits 2 seconds

While waiting two seconds, the redis client created as part of the test suite, the one that ran the monitor command, fails.

Here is the debug_output:

  redis rewrite #
    working server #
Stream connected 127.0.0.1:25052 id 0
Checking server ready state...
Send 127.0.0.1:25052 id 0: *1
$4
info

Net read 127.0.0.1:25052 id 0
Redis server ready.
on_ready called 127.0.0.1:25052 id 0
Send 127.0.0.1:25052 id 0: *1
$7
monitor

Net read 127.0.0.1:25052 id 0
Net read 127.0.0.1:25052 id 0
Net read 127.0.0.1:25052 id 0
Net read 127.0.0.1:25052 id 0
Net read 127.0.0.1:25052 id 0
Net read 127.0.0.1:25052 id 0
Net read 127.0.0.1:25052 id 0
      1) rewrites happen runthis


  0 passing (630ms)
  1 failing

  1) redis rewrite # working server # rewrites happen runthis:
     Uncaught TypeError: Cannot read property 'callback' of undefined
      at normal_reply (/aux0/brock/more-small-bug-fixes/proto.x86_64/opt/default/lib/node_modules/redis/index.js:710:27)
      at RedisClient.return_reply (/aux0/brock/more-small-bug-fixes/proto.x86_64/opt/default/lib/node_modules/redis/index.js:816:9)
      at JavascriptRedisParser.Parser.returnReply (/aux0/brock/more-small-bug-fixes/proto.x86_64/opt/default/lib/node_modules/redis/index.js:188:18)
      at JavascriptRedisParser.execute (/aux0/brock/more-small-bug-fixes/proto.x86_64/opt/default/lib/node_modules/redis/node_modules/redis-parser/lib/parser.js:491:12)
      at Socket.<anonymous> (/aux0/brock/more-small-bug-fixes/proto.x86_64/opt/default/lib/node_modules/redis/index.js:267:27)
      at readableAddChunk (_stream_readable.js:163:16)
      at Socket.Readable.push (_stream_readable.js:126:10)
      at TCP.onread (net.js:540:20)

I started hacking on the index.js file to see if I could see what was happening. In my case, when the command_obj was null, the command_queue was:

{ [String: '']
  '0': undefined,
  '1': undefined,
  _capacity: 16,
  _length: 0,
  _front: 2 }

So then I went and looked at return_reply. It correctly noticed that this redis client was monitoring. The first replyStr it received was an evalsha command and then it emitted the details. The next replyStr it received was an "eval" command, it again emitted the details. Then we get to the interesting one. Here is the replyStr it received:

1484192801.902322 [0 lua] "exists" "0.log.scope=private.service=redis-rewriter.level_name=info.1484192801867.0"

In this case it did not emit the details and continued on to the normal_reply function, causing the error to happen. I believe this is because the monitor_regex is too restrictive. Here is the monitor regex:

^[0-9]{10,11}\.[0-9]+ \[[0-9]{1,3} [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}\].*

It fails to match the [0 lua] bit of the string.

This seems very similar to issue #1037 but no one in that issue mentions the monitor command being issued at all, so I went ahead and filed this as a separate issue.

I don't have separable test code to demonstrate this issue at the moment, but if this isn't enough information, let me know and I'll try to put something together this week.

[bpytlik]

Changing the monitor_regex to:

    monitor_regex: /^[0-9]{10,11}\.[0-9]+ \[[0-9]{1,3} ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}|lua)\].*/,

solved the problem, at least for me.

[BridgeAR]

@bpytlik thank's a lot for looking into this and for the detailed description.