Lua Scripting, EVALSHA's NOSCRIPT, and Functions That Forget to Declare no-writes

A Lua script gives you one atomic round trip instead of several — and the two ways to run one (EVAL/EVALSHA versus FUNCTION/FCALL) fail differently when used carelessly.

Atomic read-then-write in one script

docker exec redis-lesson redis-cli SET stock 5
docker exec redis-lesson redis-cli EVAL "local s = tonumber(redis.call('GET', KEYS[1])); if s > 0 then return redis.call('DECR', KEYS[1]) else return -1 end" 1 stock

OK
4

The whole “check if any stock remains, then decrement” happens on the server, atomically — no other client’s command can run between the GET and the DECR inside this script, which is exactly the race the WATCH-based transaction lesson needed a retry loop to handle.

docker exec redis-lesson redis-cli SET stock 0
docker exec redis-lesson redis-cli EVAL "local s = tonumber(redis.call('GET', KEYS[1])); if s > 0 then return redis.call('DECR', KEYS[1]) else return -1 end" 1 stock

OK
-1

At zero stock, the script returns -1 and never calls DECR at all — the guard and the action are inseparable inside one script, with no window for another client to sneak in between the check and the decrement.

EVALSHA and the bug: a hash Redis has never seen

docker exec redis-lesson redis-cli SCRIPT LOAD "return redis.call('GET', KEYS[1])"

d3c21d0c2b9ca22f82737626a27bcaf5d288f99f

SCRIPT LOAD caches the script and returns its real SHA-1 hash. Now try EVALSHA with a plausible-looking but wrong hash:

docker exec redis-lesson redis-cli EVALSHA e0e1f9fabfc9d4800c877a703b823ac0578ff831 1 mykey

NOSCRIPT No matching script. Please use EVAL.

That hash was never actually loaded — it looks like a real SHA-1 but doesn’t correspond to any cached script, so Redis refuses to guess. The real hash, returned by SCRIPT LOAD a moment ago, works correctly:

docker exec redis-lesson redis-cli EVALSHA d3c21d0c2b9ca22f82737626a27bcaf5d288f99f 1 mykey

hello from lua

Functions: the bug — forgetting no-writes

# mylib.lua
#!lua name=mylib
redis.register_function('my_get', function(keys, args)
    return redis.call('GET', keys[1])
end)

docker exec -i redis-lesson redis-cli -x FUNCTION LOAD < mylib.lua
docker exec redis-lesson redis-cli FCALL my_get 1 mykey

mylib
hello from lua

Works fine through FCALL. Now try the read-only variant:

docker exec redis-lesson redis-cli FCALL_RO my_get 1 mykey

ERR Can not execute a script with write flag using *_ro command.

my_get never actually writes anything — but Redis doesn’t inspect the function body to figure that out. Without an explicit no-writes flag on registration, a function is assumed capable of writing, and FCALL_RO refuses it outright.

The fix: declare no-writes explicitly

# mylib2.lua
#!lua name=mylib2
redis.register_function{
    function_name='my_get_ro',
    callback=function(keys, args) return redis.call('GET', keys[1]) end,
    flags={'no-writes'}
}

docker exec -i redis-lesson redis-cli -x FUNCTION LOAD < mylib2.lua
docker exec redis-lesson redis-cli FCALL_RO my_get_ro 1 mykey

mylib2
hello from lua

Same logic, registered with flags={'no-writes'} this time — FCALL_RO now runs it, because the function explicitly declared what it does rather than leaving Redis to assume the worst.

Practice

docker exec redis-lesson redis-cli SCRIPT EXISTS d3c21d0c2b9ca22f82737626a27bcaf5d288f99f 0000000000000000000000000000000000000000

1
0

docker exec redis-lesson redis-cli FUNCTION LIST

library_name
mylib2
engine
LUA
functions
name
my_get_ro
description

flags
no-writes

docker exec redis-lesson redis-cli FUNCTION DELETE mylib2
docker exec redis-lesson redis-cli FUNCTION LIST

OK

Next: clustering — hash slots, resharding, and what a cluster-aware client actually needs.