Redis: Disable tooltip debug variable watch evaluation

[tw-bert]

ZeroBrane Studio (1.70; MobDebug 0.702) , Win7 x64, ZeroBraneStudioEduPack-1.70-win32.exe, redis.lua (0.33)

I just started trying out ZBS.

When debugging a complex Lua script, evaluated in Redis (4.0.6), all seems fine at first.
Debugger is connected, and ZBS halts at the first executable line.
I can step through, stack is shown, beautiful stuff.

However, after debugging deeper inside the script, when I hover over some random keywords, the buttons:

become grey:

and the whole debug session, even though still running (shown in the console), has become useless (and I have to start over again).

The issue seems to occur when hovering with the mouse over a 'redis' global, but happened at a few other hovers as well (like hovering over an OO function's parameter). Since I can't always control where my mouse is (who can), ZBS is not workable for me at the moment (and that would be a shame, it seems great otherwise).

I tried to reproduce the issue in a simpler script, but no luck so far.
I can't copy/paste the script due to NDA (and anonymizing is not feasable, too big).

So for now:
Can I disable the "tooltip debug variable watch evaluation" in some way? I tried autocomplete = false in user.lua, but that didn't do the trick.

I hope I can provide you a bug reproducable script in the future. Maybe you can provide me with some tips on how to zoom in (like: can I turn on a system debug log, or can I capture tracing of redis.lua, or insert some debug code in redis.lua?)

[tw-bert]

Could be related: Before the issue is in effect, some of the vars show {"[[contents trimmed, consider using maxlen 0]]"} (which is in redis.lua)

[pkulchenko]

Yes, it seems like the value is too large to handle for the redis protocol. You may try adding noeval option to the debugger, which should disable tooltip (and the Watch window, which probably has the same issue):

diff --git a/redis.lua b/redis.lua
index 752f594..b3a6335 100644
--- a/redis.lua
+++ b/redis.lua
@@ -1544,7 +1544,7 @@ local interpreter = {
       end
     end
 
-    if rundebug then ide:GetDebugger():SetOptions() end
+    if rundebug then ide:GetDebugger():SetOptions({noeval=true}) end
     local pkgcfg = pkg:GetConfig()
     local redis = " --instance "..address
     local controller = " --controller "..ide:GetDebugger():GetHostName()..":"..ide:GetDebugger():GetPortNumber()

I'll need to try to reproduce this and thing of a better fix.

You can also try setting redis={maxlen=0} (or some other value) in the IDE config to see if this helps.

It would be great if you could try both of these options.

[tw-bert]

Thanks, will try. Which file is the IDE config? The ini file in appdata?

[pkulchenko]

The docs are here: https://studio.zerobrane.com/doc-configuration; you can just go to Edit | Preferences | Settings: User.

[tw-bert]

redis={maxlen=0} (or larger value) works fine. It is not related to the issue in itself.

{noeval=true} works, the IDE is a lot more stable now. Amazingly, the stack still shows the vars and values. Watches and tooltips stopped working (good).

It also probably helps with tracking down the cause.
At the point (about 4 levels deep in the stack, OO methods, simple prototyping used, dicts and normal vars passed) where I could reproduce the issue, I can now do the following to force the faulty behaviour:

• Go to the Remote Console
• Type 1 enter
• Nothing is returned, buttons are grey again

When I do this at the top of the program (auto breakpoint), a 1 is returned, correct behaviour.

Which part of redis.lua would be useful to trace?

[pkulchenko]

Can you check if you are using v0.33 of the redis plugin, as there were some recent changes that fixed execution of commands in the console. I definitely tested the execution of commands after recent IDE changes, so I would expect it to work with 0.33, unless there is something specific to your code/objects.

[tw-bert]

Yes, 0.33

[tw-bert]

This might be a trivial question, but can I debug redis.lua inside ZBS? Just setting a breakpoint doesn't hit it.

[tw-bert]

I definitely tested the execution of commands after recent IDE changes, so I would expect it to work with 0.33, unless there is something specific to your code/objects.

Just to be clear : it is working fine (see "correct behaviour" above) at first. But while debugging deep down the stack, it stops working ánd pollutes the session to an unusable state.

[pkulchenko]

@tw-bert, I still can't reproduce this issue. Can you try reproducing it with redis = {verbose = true} and include the debugging output (especially around the failing command)? Maybe it will help to show what's going on there...

[tw-bert]

@pkulchenko , I think I managed to create a Lua script that reproduces it (parts of the NDA script, anonymized). Here it is:

local cA1234PSIP = ARGV[1]
local cA2222PSIP = tonumber(ARGV[2])
local dtMMMMMMMMMMMMMMPSIP = ARGV[3]
local bSSSSSSSSSSSSSSSPSIP = string.lower(ARGV[4]) == 'true'
local bDDDDDPSIP = string.lower(ARGV[5]) == 'true'
local iSSSSSPSIP = (#ARGV < 6 and nil) or ARGV[6] 

local function round_n(x, n)
  n = math.pow(10, n or 0)
  x = x * n
  if x >= 0 then x = math.floor(x + 0.5) else x = math.ceil(x - 0.5) end
  return x / n
end

local a1t = {new = function(self, o) o = o or {} setmetatable(o, self) self.__index = self return o end}
function a1t:zfind()
  local xRet,tVal,bFound=false
  local cKey=string.upper(self.PKO89)
  local tRRRa1t=redis.call(
    'zrangebylex',
    'LLLa1t.d',
    '[' .. cKey .. '\000',
    '(' .. cKey .. '\001')
  if #tRRRa1t == 1 then
    xRet=tRRRa1t[1]:match('.-%z\128%z(.*)')
    tVal=cmsgpack.unpack(xRet)
    bFound = true
    local a1t=self
    a1t.PKO89  = tVal[3]
    a1t.a1XyZ1 = tVal[7]
    a1t.a1XyZ2 = tVal[8]
    a1t.a1XyZ3 = tVal[9]
    a1t.LLLLN  = tVal[35]
    a1t.O6YTWS = tVal[23]
  end
  return bFound
end

local c2x = {new = function(self, o) o = o or {} setmetatable(o, self) self.__index = self return o end}
function c2x:zfind()
  local xRet,tVal,bFound=false
  local cKey=string.format("%05d",self.c2xno)
  local tRRRc2x=redis.call(
    'zrangebylex',
    'MMMc2x.d',
    '[' .. cKey .. '\000',
    '(' .. cKey .. '\001')
  if #tRRRc2x == 1 then
    xRet=tRRRc2x[1]:match('.-%z\128%z(.*)')
    tVal=cmsgpack.unpack(xRet)
    bFound = true
    local c2x = self
    c2x.c2xno = tVal[2]
    c2x.c2xnm = tVal[5]
    c2x.c2xcy = tVal[9]
    c2x.uTygF = tVal[26]
    c2x.uTPuY = tVal[27]
  end
  return bFound
end

local sc_fbLjUgfR_liqRR = { iKLhjuYtfGtrE = 0, }

local KOHUhgR = {}
function KOHUhgR:JkuiHhgyuTrdfRefghUyq(bklIhhbXc2x)
return false
end

local sc_jklgTyggfhRgjhiuY_r = {}
function sc_jklgTyggfhRgjhiuY_r:getJKujhJJtgRwfGQ(bklIhhbXa1t, bklIhhbXc2x, bklIhhbXbbb, dtKlpppQutRKpRRtIP, ttKlpppQutRactie, tta1tactie, tRRRLocal)
  return false
end

local sc_kjUUYqhgfA_liqRR = {}
function sc_kjUUYqhgfA_liqRR:JKlqhYgfvTfcD(iSarCdIP)
  return false
end

local sc_h7tlib_iUHgtQ_r = {}
function sc_h7tlib_iUHgtQ_r:UYRUHgtQPKlOuE(bklIhhbXa1t, dtKlpppQutRKpRRtIP, iRTygFIP, tRRRLocal)
  tRRRLocal.fUHgtQPKlOuE=0.077
end

local sc_JkLPoqFcX_r = {}
function sc_JkLPoqFcX_r:UYRKoUIftGrM(bklIhhbXa1t, bklIhhbXc2x, iLkOnHHtgroup)
end

local sc_h7tlib_r = {}
function sc_h7tlib_r:UYRPkIUtREdWC(bklIhhbXa1t)
  return 12345
end

local sc_Jkk8rikel_aQfxYY_r = {}
function sc_Jkk8rikel_aQfxYY_r:M75PklUytrDfR(bklIhhbXa1t, bklIhhbXc2x, bklIhhbXbbb)
  return false
end

local sc_lifCdreSdwYu_r = {}
function sc_lifCdreSdwYu_r:c2xPk6UYRkUye(bklIhhbXc2x,bklIhhbXbbb)
end
function sc_lifCdreSdwYu_r:UYRa1kksswPi9iwppquH(bklIhhbXa1t, iIDJkkLLNNggVfDrS, tRRRLocal)
  tRRRLocal.fPi9iwKlOuELV=0.0
  tRRRLocal.irDddSwEoYYtT1tKlOuE=0.0
  tRRRLocal.fPi9iwKlOuEVV=0.0
end

local ret='OK'

return ret

I still have tooltips and watches disabled.
If I set a breakpoint at line 107 (local ret='OK'), hit F5 two times, go to the Remote Console, and type sc_Jkk8rikel_aQfxYY_r + enter, the undesired unresponsive state is reproduced. The verbose logging says in response to this command:

<redis sent> *1\r\n$1\r\nP\r\n
<redis rcvd> *18
<redis rcvd> +<value> cA1234PSIP = \"T05113\"
<redis rcvd> +<value> cA2222PSIP = 1611
<redis rcvd> +<value> dtMMMMMMMMMMMMMMPSIP = \"2017/12/19\"
<redis rcvd> +<value> bSSSSSSSSSSSSSSSPSIP = false
<redis rcvd> +<value> bDDDDDPSIP = false
<redis rcvd> +<value> iSSSSSPSIP = nil
<redis rcvd> +<value> round_n = \"function@0x193b150\"
<redis rcvd> +<value> a1t = {[\"zfind\"]=\"function@0x19074c0\"; [\"new\"]=\"function@0x1964cc0\"}
<redis rcvd> +<value> c2x = {[\"zfind\"]=\"function@0x18bc4b0\"; [\"new\"]=\"function@0x195d060\"}
<redis rcvd> +<value> sc_fbLjUgfR_liqRR = {[\"iKLhjuYtfGtrE\"]=0}
<redis rcvd> +<value> KOHUhgR = {[\"JkuiHhgyuTrdfRefghUyq\"]=\"function@0x191c5d0\"}
<redis rcvd> +<value> sc_jklgTyggfhRgjhiuY_r = {[\"getJKujhJJtgRwfGQ\"]=\"function@0x18bf330\"}
<redis rcvd> +<value> sc_kjUUYqhgfA_liqRR = {[\"JKlqhYgfvTfcD\"]=\"function@0x1964d20\"}
<redis rcvd> +<value> sc_h7tlib_iUHgtQ_r = {[\"UYRUHgtQPKlOuE\"]=\"function@0x18d7db0\"}
<redis rcvd> +<value> sc_JkLPoqFcX_r = {[\"UYRKoUIftGrM\"]=\"function@0x18ba7f0\"}
<redis rcvd> +<value> sc_h7tlib_r = {[\"UYRPkIUtREdWC\"]=\"function@0x192e9e0\"}
<redis rcvd> +<value> sc_Jkk8rikel_aQfxYY_r = {[\"M75PklUytrDfR\"]=\"function@0x1920050\"}
<redis rcvd> +<value> sc_lifCdreSdwYu_r = {[\"c2xPk6UYRkUye\"]=\"function@0x18c1ac0\"; [\"UYRa1kksswPi9iwppquH\"]=\"function@0x18d81a0\"}
<redis sent> *2\r\n$1\r\nE\r\n$1046\r\nlocal cA1234PSIP = \"T05113\"; local cA2222PSIP = 1611; local dtMMMMMMMMMMMMMMPSIP = \"2017/12/19\"; local bSSSSSSSSSSSSSSSPSIP = false; local bDDDDDPSIP = false; local iSSSSSPSIP = nil; local round_n = \"function@0x193b150\"; local a1t = {[\"zfind\"]=\"function@0x19074c0\"; [\"new\"]=\"function@0x1964cc0\"}; local c2x = {[\"zfind\"]=\"function@0x18bc4b0\"; [\"new\"]=\"function@0x195d060\"}; local sc_fbLjUgfR_liqRR = {[\"iKLhjuYtfGtrE\"]=0}; local KOHUhgR = {[\"JkuiHhgyuTrdfRefghUyq\"]=\"function@0x191c5d0\"}; local sc_jklgTyggfhRgjhiuY_r = {[\"getJKujhJJtgRwfGQ\"]=\"function@0x18bf330\"}; local sc_kjUUYqhgfA_liqRR = {[\"JKlqhYgfvTfcD\"]=\"function@0x1964d20\"}; local sc_h7tlib_iUHgtQ_r = {[\"UYRUHgtQPKlOuE\"]=\"function@0x18d7db0\"}; local sc_JkLPoqFcX_r = {[\"UYRKoUIftGrM\"]=\"function@0x18ba7f0\"}; local sc_h7tlib_r = {[\"UYRPkIUtREdWC\"]=\"function@0x192e9e0\"}; local sc_Jkk8rikel_aQfxYY_r = {[\"M75PklUytrDfR\"]=\"function@0x1920050\"}; local sc_lifCdreSdwYu_r = {[\"c2xPk6UYRkUye\"]=\"function@0x18c1ac0\"; [\"UYRa1kksswPi9iwppquH\"]=\"function@0x18d81a0\"};return sc_Jkk8rikel_aQfxYY_r \r\n

The sc_Jkk8rikel_aQfxYY_r + enter -> returns nothing, and debugger step buttons are grey. Output tab title is 'Output (running)' instead of 'Output (suspended)'. Asking for sc_Jkk8rikel_aQfxYY_r again gives:

Can't evaluate the expression while the application is running.

[tw-bert]

I might add that even changing the variable names to shorter names caused differences in reproducing the issue.

[pkulchenko]

@tw-bert, after a bit of experimenting, I think it boils down to the size of the package that is being sent to redis. For example, this works (the size of the package is 1024):

<redis sent> *2\r\n$1\r\nE\r\n$1024\r\nlocal cA1234PSIP = "a"; local cA2222PSIP = 1; local dtMMMMMMMMMMMMMMPSIP = "b"; local bSSSSSSSSSSSSSSSPSIP = true; local bDDDDDPSIP = true; local iSSSSSPSIP = nil; local round_n = "function@0x7f84c1d008d0"; local a1t = {["zfind"]="function@0x7f84c1d005a0"; ["new"]="function@0x7f84c1d00260"}; local c2x = {["zfind"]="function@0x7f84c1d006a0"; ["new"]="function@0x7f84c1d00a30"}; local KOHUhgR = {["JkuiHhgyuTrdfRe"]="function@0x7f84c1d00230"}; local sc_jklgTyggfhRgjhiuY_r = {["getJKujhJJtgRwfGQ"]="function@0x7f84c1d00f20"}; local sc_kjUUYqhgfA_liqRR = {["JKlqhYgfvTfcD"]="function@0x7f84c1d00fc0"}; local sc_h7tlib_iUHgtQ_r = {["UYRUHgtQPKlOuE"]="function@0x7f84c1d01060"}; local sc_JkLPoqFcX_r = {["UYRKoUIftGrM"]="function@0x7f84c1d010c0"}; local sc_h7tlib_r = {["UYRPkIUtREdWC"]="function@0x7f84c1d02390"}; local sc_Jkk8rikel_aQfxYY_r = {["M75PklUytrDfR"]="function@0x7f84c1d02430"}; local sc_lifCdreSdwYu_r = {["c2xPk6UYRkUye"]="function@0x7f84c1d024d0"; ["UYRa1kksswPi9iwppquH"]="function@0x7f84c1d02530"};return 1+2 \r\n
<redis rcvd> *1
<redis rcvd> +<retval> 3

But this hangs (almost the same payload, but the size of the package is 1025):

<redis sent> *2\r\n$1\r\nE\r\n$1025\r\nlocal cA1234PSIP = "a"; local cA2222PSIP = 1; local dtMMMMMMMMMMMMMMPSIP = "b"; local bSSSSSSSSSSSSSSSPSIP = true; local bDDDDDPSIP = true; local iSSSSSPSIP = nil; local round_n = "function@0x7f84c1c3d850"; local a1t = {["zfind"]="function@0x7f84c1c355c0"; ["new"]="function@0x7f84c1c35590"}; local c2x = {["zfind"]="function@0x7f84c1c356b0"; ["new"]="function@0x7f84c1c35680"}; local KOHUhgR = {["JkuiHhgyuTrdfRea"]="function@0x7f84c1c3dde0"}; local sc_jklgTyggfhRgjhiuY_r = {["getJKujhJJtgRwfGQ"]="function@0x7f84c1c357e0"}; local sc_kjUUYqhgfA_liqRR = {["JKlqhYgfvTfcD"]="function@0x7f84c1c3e0d0"}; local sc_h7tlib_iUHgtQ_r = {["UYRUHgtQPKlOuE"]="function@0x7f84c1c3e170"}; local sc_JkLPoqFcX_r = {["UYRKoUIftGrM"]="function@0x7f84c1c3e210"}; local sc_h7tlib_r = {["UYRPkIUtREdWC"]="function@0x7f84c1c3e2b0"}; local sc_Jkk8rikel_aQfxYY_r = {["M75PklUytrDfR"]="function@0x7f84c1c3e350"}; local sc_lifCdreSdwYu_r = {["c2xPk6UYRkUye"]="function@0x7f84c1c3e3f0"; ["UYRa1kksswPi9iwppquH"]="function@0x7f84c1c3e450"};return 1+2 \r\n

I've tested various values and anything less than 1025 works, but anything larger than 1024 fails. It looks like the server is waiting for some further data, which effectively blocks the debugger.

What version of Redis are you using?

@itamarhaber, can you take a look at this? Basically, a request sending E (eval) command in the debugger with a value larger than 1024 bytes appears to hang. Is there a limit on the payload size for this command?

Just to remind, since the eval is done in a different callframe, I'm sending the values of known local variables to allow eval commands to return proper values, which increases the command size.

[pkulchenko]

@tw-bert, given the situation, I made a patch that limits the payload that is being sent when console, watches, or tooltips are used, which should fix the issue at the cost of the results not always being correct (as it includes local values until it hits the limit, so some values that the expression is using may not get included). Here is the patch (line numbers may be a bit off, as I have changes that I haven't pushed yet, but you get the idea):

diff --git a/redis.lua b/redis.lua
index 6cd331c..b333137 100644
@@ -1708,10 +1708,16 @@ local function getvars(response)
   end
   return res
 end
-local function getvarsaslocals(response)
+local function getvarsaslocals(response, max)
   local vars = getvars(response)
   if not vars or #vars == 0 then return "" end
-  return "local "..table.concat(vars, "; local ")..";"
+  local s = ""
+  for _, v in ipairs(vars) do
+    local news = s.."local "..v..";"
+    if #news > max then break end
+    s = news
+  end
+  return s
 end
 local function getvarsastable(response)
   local vars = getvars(response)
@@ -1890,7 +1896,7 @@ while true do
       if func then
         -- evaluation is done in a different environment, so capture local variables
         -- to use in the chunk evaluation to make their values available
-        local vars = getvarsaslocals(check(client:ldbprint()))
+        local vars = getvarsaslocals(check(client:ldbprint()), 1024-#chunk)
         local msg, err = client:ldbeval(vars..chunk)
         -- if there is an error, try without preamble, as it has a better error message
         if msg and geterror(msg) then msg, err = client:ldbeval(chunk) end

I'm still interested to know if this is expected behavior or not.

[tw-bert]

@pkulchenko Great you can repro it. The patch is a big improvement, I can finally use ZBS the way you intended, great stuff indeed. Glad that we boiled down to the root cause of this issue.

What version of Redis are you using?

• 4.0.6, as stated in 1st post

I'm still seeing some strange behaviour (nowhere as strange as before the patch though), which @itamarhaber might like to look at as well.

When I repeatedly ask for the value of the same local var, the response is inconsistent:

As to be expected, this happens in ZBS tooltips as well.

[pkulchenko]

4.0.6, as stated in 1st post

Missed it there; thanks for update and for testing it.

I'm still seeing some strange behaviour (nowhere as strange as before the patch though), which @itamarhaber might like to look at as well.
When I repeatedly ask for the value of the same local var, the response is inconsistent:

Can you run it with redis = {verbose = true}? I suspect the order of variables changes between commands and that variable doesn't get to be included, so is treated as a missing global.

I'll try to reproduce as well.

[tw-bert]

Sure: zbs_redis.txt
Should be easy to repro, after fresh restart, sc_lifCdreSdwYu_r succeeds 1st+2nd time and fails 3rd time.

[pkulchenko]

I see ldb_eval:1: '<eof>' expected reported in the log:

<redis sent> *2\r\n$1\r\nE\r\n$1022\r\nlocal cA1234PSIP = \"T05113\";local cA2222PSIP = 1611;local dtMMMMMMMMMMMMMMPSIP = \"20180102.174127447867\";local bSSSSSSSSSSSSSSSPSIP = false;local bDDDDDPSIP = false;local iSSSSSPSIP = nil;local round_n = \"function@0x9e97b0\";local a1t = {[\"zfind\"]=\"function@0xa02710\"; [\"new\"]=\"function@0x9e3d10\"};local c2x = {[\"zfind\"]=\"function@0x9e9930\"; [\"new\"]=\"function@0xa02740\"};local sc_fbLjUgfR_liqRR = {[\"iKLhjuYtfGtrE\"]=0};local KOHUhgR = {[\"JkuiHhgyuTrdfRefghUyq\"]=\"function@0x9edb20\"};local sc_jklgTyggfhRgjhiuY_r = {[\"getJKujhJJtgRwfGQ\"]=\"function@0x9ee5d0\"};local sc_kjUUYqhgfA_liqRR = {[\"JKlqhYgfvTfcD\"]=\"function@0x9ee630\"};local sc_h7tlib_iUHgtQ_r = {[\"UYRUHgtQPKlOuE\"]=\"function@0x9fe010\"};local sc_JkLPoqFcX_r = {[\"UYRKoUIftGrM\"]=\"function@0xa02ee0\"};local sc_h7tlib_r = {[\"UYRPkIUtREdWC\"]=\"function@0xa02f40\"};local sc_Jkk8rikel_aQfxYY_r = {[\"M75PklUytrDfR\"]=\"function@0xa01840\"};local sc_lifCdreSdwYu_r = {[\"c2xPk6UYRkUye\"]=\"function@0x9fed10\"; [\"UYRa1kksswPi9iwppquH\"]=\"function@0x9f34d0\"};return sc_lifCdreSdwYu_r \r\n
<redis rcvd> *1
<redis rcvd> +<error> ldb_eval:1: '<eof>' expected
<redis sent> *2\r\n$1\r\nE\r\n$25\r\nreturn sc_lifCdreSdwYu_r \r\n
<redis rcvd> *1
<redis rcvd> +<error> ldb_eval:1: Script attempted to access nonexistent global variable 'sc_lifCdreSdwYu_r'

Not sure what this means, as the content being sent is exactly the same as the one that works. @itamarhaber, any idea?

[tw-bert]

@pkulchenko You might have missed one Q:

can I debug redis.lua inside ZBS?

[pkulchenko]

can I debug redis.lua inside ZBS?

Yes, missed it. The answer is complicated, as redis.lua includes two parts: one that is loaded as a plugin and the other that is launched as a standalone lua script to act as a proxy between the IDE and the redis debugger. Both can be debugged inside ZBS, but this needs to be approached a bit differently (or rather you need to start debugging in two different places to make it work).

In both cases you'd need to switch the debugging port (as described in this FAQ answer).

[tw-bert]

@pkulchenko Thanks for the info, great that it's possible.

[pkulchenko]

@tw-bert, pushed the changes that we discussed earlier and closed the ticket as this is all I can do given the information we have.

I also looked at the Redis code, but don't see where 1024 byte limit comes into play and don't have any additional details on the <eof> issue. I'll update if there is more info from @itamarhaber on this.

[tw-bert]

@pkulchenko Yes, the two detected issues are not ZBS related, as far as we can tell. Must be patched or clarified by the redis guys. I'll give @itamarhaber some time to respond, and possibly open a redis issue at a later time.

[tw-bert]

@pkulchenko https://pauladamsmith.com/articles/redis-under-the-hood.html possibly sheds some light on the 1024 byte limit we are seeing. Still nothing to do with ZBS of course.

[itamarhaber]

Given the excellent reproduction, I can clearly see the 1KB limit hardcoded in the Redis debugger's code (https://github.com/antirez/redis/blob/4.0/src/scripting.c#L1807 and the logic after https://github.com/antirez/redis/blob/4.0/src/scripting.c#L2254). Put differently, but not documented AFAIK, ldb's arguments should be < 1025 bytes.

This may be a documentation and/or a code issue w/ Redis, but before trying to address that I want to understand the need for such a big e command argument, i.e. why does the entire script get evaluated on a tooltip hover? AFAIR, the p command should be used in its stead to print the variable's value.

[pkulchenko]

Put differently, but not documented AFAIK, ldb's arguments should be < 1025 bytes.

So it looks like the applied fix was correct then.

before trying to address that I want to understand the need for such a big e command argument, i.e. why does the entire script get evaluated on a tooltip hover? AFAIR, the p command should be used in its stead to print the variable's value.

@itamarhaber, it's not the entire script, but a specially constructed fragment; it's the side-effect of the execution done in a different callframe: "Just to remind, since the eval is done in a different callframe, I'm sending the values of known local variables to allow eval commands to return proper values, which increases the command size."

I think p only works for simple variables, but not for expressions, right?

There was also an issue with repeated requests, as described in this comment. I put the debugger output with additional details in this comment.

[itamarhaber]

I think p only works for simple variables, but not for expressions, right?

Jup. The special construction of e is also sort of coming back to me.

I intuit that the repeated requests combined with 1024+ args breaks the parser, which is an issue/misuse/documentation fix :) That being the case, I think it should be raised in the relevant repo: redis/redis#4600

[tw-bert]

@itamarhaber The issue with repeated requests was after Paul's fix, so: below 1K