Use EVALSHA to run a script that is already in the server's script cache, identified by its SHA1 digest.
It behaves exactly like EVAL but sends only the 40-character digest instead of the script body, which keeps the request small when a script is called often. The digest is what SCRIPT LOAD returns, and it is also computed as a side effect of any EVAL call.
Locking behaviour comes from the cached script body, not from the call: the script takes the global lock unless its shebang sets the allow-key-locking flag, in which case only the keys passed in KEYS are locked. Because the flag lives in the body, changing it means loading a new script and calling the new digest. See Key-Based Locking.
When the script is not in the cache the server replies with a NOSCRIPT error, and the client is expected to fall back to EVAL. Most client libraries do this automatically. The cache does not survive a restart and is cleared by SCRIPT FLUSH, so applications must always be able to resend the script body.
Syntax#
Arguments#
| Argument | Required | Repeatable | Description |
|---|---|---|---|
<sha1> | Yes | No | SHA1 digest of a script cached with SCRIPT LOAD. |
<numkeys> | Yes | No | Number of key arguments that follow. |
<key> | No | Yes | Redis key targeted by the command. |
<arg> | No | Yes | Additional argument, available to the script as ARGV. |
Important points#
numkeysmust equal the number of key arguments that immediately follow it; remaining arguments are available to the script or function as ordinary arguments.- The cached script takes the global lock unless its shebang sets the
allow-key-lockingflag. See Key-Based Locking. - A script queued inside a
MULTI/EXECtransaction always runs under the global lock, even when it setsallow-key-locking. Call it directly if you want per-key locking. - Pass every key the script touches through
KEYSwhether or notallow-key-lockingis set. A key built inside the script is read from disk under the lock when it is not in memory, and it is rejected outright when the flag is set. See Dynamic Keys and Latency.
Reply conversion#
redis.setresp() and the RESP2 and RESP3 conversions applied to redis.call replies work exactly as they do for EVAL.
Response#
The reply reports the result of the operation. Error replies have the same shape in RESP2 and RESP3 and are surfaced as exceptions by the SDKs below.
| Protocol | Reply |
|---|---|
| RESP2 | Reply produced by the cached script |
| RESP3 | Reply produced by the cached script |
Client libraries often decode bulk strings, maps, sets, and numeric strings into language-native values. The table describes the Redis wire reply.
Examples#
TCP examples use the TLS REDIS_URL from the Upstash console. REST examples use UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN.