Use SCRIPT EXISTS to check which of the given SHA1 digests are present in the script cache.
The reply holds one 1 or 0 per digest, in the order they were given. Client libraries use it to find out, in a single call, which of their scripts still need to be loaded before they can be invoked with EVALSHA, instead of discovering the gap through a NOSCRIPT error at call time.
Syntax#
Arguments#
| Argument | Required | Repeatable | Description |
|---|---|---|---|
<sha1> | Yes | Yes | SHA1 digest of a script cached with SCRIPT LOAD. |
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 | Array of integers, one per SHA1 digest |
| RESP3 | Array of integers, one per SHA1 digest |
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.
Redis CLI
REST API
First, load the script. The response contains its SHA1 digest,
098e0f0d1448c0a81dafe820f66d460eb09263da.
The second response is { "result": [1] } while the script is cached, or
{ "result": [0] } if it has been removed.
See REST API for request and response conventions.