A Lua script sent to Redis with EVAL is described as executing atomically. What exactly does that guarantee, what does it cost the rest of the server, and what can an operator do about a script that will not finish?

## What atomic means here Redis executes client commands on a single command-processing thread. When a script arrives via `EVAL`/`EVALSHA`, the server runs the whole script as one such unit of work: the Lua interpreter runs, its `redis.call` invocations execute inline against the data, and only when the script returns does Redis move on to the next client's command. So the guarantee is **isolation by serialization**: no other client's command is interleaved between any two operations of the script. If your script does ```lua local v = tonumber(redis.call('GET', KEYS[1]) or '0') if v < tonumber(ARGV[1]) then return redis.call('INCR', KEYS[1]) end return v ``` nobody can change `KEYS[1]` between the `GET` and the `INCR`. This is why Lua is the standard answer for conditional, multi-step, multi-key updates in Redis — a capped counter, a token bucket, a compare-and-delete lock release. What atomicity does **not** give you is rollback. If the fifth command in a script fails or the script raises a Lua error after four successful writes, those four writes stand. Atomicity means "nothing interleaves", not "all or nothing". ## The cost: the script owns the server Because it is one unit of work on the only command-processing thread, the script's runtime is dead time for every other connection. The relevant discipline is the same as for any command: know the complexity of what you call and bound it. - `redis.call('KEYS', '*')` inside a script is O(N) over the whole keyspace — a stall proportional to the database. - Looping `for i = 1, 1000000` over `LPOP` is a million commands' worth of work in one blocking unit. - Fetching a big collection into Lua (`LRANGE key 0 -1` on a huge list) costs both time and a large temporary allocation. Symptoms are latency spikes across all clients, client-side timeouts, and — importantly — health-check timeouts. A script that runs longer than a Sentinel's `down-after-milliseconds` or a Cluster's node timeout can cause the node to be judged failed and trigger an unnecessary failover. ## The BUSY state Redis does not preempt scripts, but it does not leave you blind either. The `busy-reply-threshold` configuration (Redis 7.0 name; earlier `lua-time-limit`, default 5000 ms) controls when the server, while still running the script, begins responding to other clients with: ``` (error) BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE. ``` This is a signal, not a timeout — the script is not aborted. In that state the server accepts only `SCRIPT KILL` (or `FUNCTION KILL` for Functions) and `SHUTDOWN NOSAVE`. ## Killing — and when you cannot `SCRIPT KILL` terminates the running script and returns an error to its caller. It is refused with `UNKILLABLE` if the script has **already executed a write command**. The reason is the absence of rollback plus replication integrity: the writes performed so far may already be queued for propagation to replicas and the AOF, and aborting mid-way would leave the primary in a state that cannot be described coherently to them. When a writing script is stuck, the only remedy is `SHUTDOWN NOSAVE` — kill the server without writing an RDB — losing everything since the last save point (or relying on the AOF, if enabled, up to its last fsync). This is a genuine data-loss event, which is why "bound your scripts" is not pedantry. Two mitigations follow directly: 1. **Declare read-only scripts as such.** With the `no-writes` shebang flag (7.0) or `EVAL_RO`/`EVALSHA_RO`, the script cannot write, and therefore is always killable. 2. **Do writes last.** A script that computes first and writes at the end has a large killable window and a small unkillable one. ## Practical rules - Treat a script as a single command whose complexity is the sum of its parts; aim for microseconds to low milliseconds. - Never iterate an unbounded collection inside a script; pass a bounded batch size in `ARGV` and let the caller loop. - Avoid `KEYS`, unbounded `LRANGE`/`ZRANGE`/`SMEMBERS`, and unbounded `while` loops. - Watch `SLOWLOG` — script executions appear there — and `INFO commandstats` / latency percentiles to catch regressions. - If the work is genuinely large, do it outside Redis or chunk it, rather than buying atomicity at the price of a server-wide stall. ## Why the guarantee is worth the constraint The reason this bargain is acceptable is that the alternative — a lock protocol between clients — costs more round trips, introduces failure modes when a client dies holding a lock, and still cannot make a multi-key update indivisible. A short script buys real atomicity for the cost of the microseconds it runs. The failure mode only appears when the script stops being short.