StackExchange
Address misleading documentation
Explicitly mention that if previously loaded 'Lua' script was evaluated by it's 'SHA-1' hash, and that hash doesn't exist on the redis server anymore (e.g. server reboot, SCRIPT FLUSH, etc) - it will be reloaded with the 'SCRIPT LOAD' redis command.
Resolves #2443
Might be a good idea to update the markdown documentation page as well with this PR. I'll commit new changes for it later.
~~This whole abstraction: LoadedLuaScript seems kind of weird to me in it's current state. I guess it's not deprecated due to compatibility concerns. But I was wondering is there another reason that I might be unaware of ? Running SCRIPT EXIST sha1 before evaluating the script by it's hash does not sound ideal to me, but let's say we're always checking for a single script the complexity should be O(1). Are there any gains to be made if a check was introduced to evaluate the script by it's hash - if it exists, and if not - evaluate it with EVAL.~~
Update: This seems to be irrelevant.
Thing is... I'm not sure it is wrong. It should still hit the local script cache against our endpoint instance, so once we've seen it load: it should switch to the hash version. I'd want to investigate this via redis-cli monitor before updating any docs (noting that it will still use the full script initially)
@mgravell Thanks for the heads up, I saw that EVAL was being used after a SCRIPT LOAD command was executed to load a script that previously was cached. When I saw that the changes to the loaded script abstraction, that do not invoke the ScriptEvaluate(byte[] hash, ...) overload, I presumed it always used the EVAL redis command. I'm still new to this codebase, so I've missed that local cache instance. Can you also verify that this is the behavior you're seeing in the monitor logs? Unfortunately, I cannot share examples, but I can probably setup a sandbox project that replicates the problem.
I'll re-word my changes to make it clear what the current behavior is.