Redis has both FCALL and FCALL_RO for invoking server-side functions. What is the difference, what must the function declare for FCALL_RO to be accepted, and why would you use it?

## Two entry points, one guarantee Redis 7 exposes `FCALL fname numkeys …` and `FCALL_RO fname numkeys …`. They invoke the same registered Lua callback. The difference is a **contract**: `FCALL_RO` is only accepted if the function was registered with the `no-writes` flag, and while running under that flag any attempt to execute a write command from Lua fails with an error rather than mutating data. Registration looks like this: ``` redis.register_function{function_name='top_scores', callback=top, flags={'no-writes'}} ``` Without the flag, `FCALL_RO top_scores …` is rejected outright — Redis will not "try it and see". This is deliberate: the server cannot statically analyse arbitrary Lua, so it relies on the author's declaration plus runtime enforcement of it. ## Why a read-only declaration is worth having **Replica execution.** A replica must never originate a write; a normal `FCALL` is therefore not runnable there. A `no-writes` function is, so `FCALL_RO` lets you push computed reads — aggregations, filtered lookups, multi-key joins done in Lua — to replicas and scale read throughput. Client libraries that already do read-from-replica routing can route `FCALL_RO` the same way they route `GET`. **Availability of reads when writes are blocked.** A primary may be refusing writes: `maxmemory` reached with a write-refusing policy, or `min-replicas-to-write` unsatisfied. Read-only functions still work. Pair with `allow-oom` if the function must run even under memory pressure (only sensible for functions that genuinely allocate nothing significant), and with `allow-stale` if a replica should serve it even when its link to the primary is down and `replica-serve-stale-data` semantics apply — a stale-flagged function may only touch commands that are themselves allowed on stale data. **Security and blast radius.** ACL rules can permit `FCALL_RO` and deny `FCALL`, giving reporting or analytics clients server-side compute without the ability to change data. That is much stronger than trusting that a particular script "doesn't write". **Killability.** This is the operational reason seniors care. A function or script that has already performed a write cannot be aborted, because Redis has no rollback — killing it mid-way would leave a partial effect that has possibly already been propagated. So `FUNCTION KILL` refuses, and the only way out of an infinite loop after a write is `SHUTDOWN NOSAVE`, which discards unsaved data. A `no-writes` function has, by construction, produced no effect, so `FUNCTION KILL` can terminate it cleanly once `busy-reply-threshold` has elapsed. Declaring `no-writes` where it is true is therefore a resilience measure, not decoration. ## Replication consequence A read-only function produces no effects, so nothing is propagated to replicas or the AOF from it. A writing function propagates the write commands it executed (effects replication). That means `FCALL_RO` on a replica is genuinely local work with no divergence risk — the same input can even yield different bytes on different nodes without corrupting anything, because nothing is written. ## The other flags - `allow-oom` — permits the call when the server is over `maxmemory`. Without it, Redis refuses to start functions that may write once memory is exhausted. Use only when the function cannot grow the dataset. - `allow-stale` — permits execution on a replica with a broken link to the primary when stale-data serving is restricted; combine with `no-writes`, and inside the function only stale-safe commands may be called. `redis.setresp` and command availability differ here, so keep such functions minimal. - `no-cluster` — the library refuses to load on a node running in cluster mode; used for logic that assumes a single keyspace. ## Practical guidance Flag every genuinely read-only function `no-writes` by default. Do not flag a function that writes "sometimes" — a single conditional write makes the declaration false and Redis will error at exactly the wrong moment, in the rare branch, in production. If a function has a read fast path and a rare write path, split it into two functions and let the caller pick, so the common path stays replica-routable and killable. Finally, remember `FCALL_RO` limits *writes*, not *cost*. A read-only function that scans a million-element collection still blocks the whole server for the duration — on a replica, that stalls every reader on that node.