Client unblocked
Production Risk
Low. This is an informational message about an administrative action.
This is not an error, but a special push message sent to a client that was blocked (e.g., by BLPOP or WAIT) and was unblocked by the `CLIENT UNBLOCK` command. It signals that the blocking command was aborted.
- 1An administrator manually ran `CLIENT UNBLOCK` on the client's ID.
- 2The `CLIENT UNBLOCK` command was called with the TIMEOUT option, and the client was unblocked due to a timeout.
- 3The client was unblocked with the ERROR option, which sends this message.
Client 1 is blocked on `BLPOP`. An administrator on Client 2 unblocks it.
# In Client 1: BLPOP mylist 0 # In Client 2 (after getting Client 1's ID): CLIENT UNBLOCK <client-id> ERROR
expected output
(error) UNBLOCKED
Fix 1
Handle the UNBLOCKED message in the client
WHEN If your application logic needs to know a command was aborted
// pseudocode
try {
redis.blpop("mylist", 0);
} catch (e) {
if (e.message.includes("UNBLOCKED")) {
// The command was cancelled, handle it gracefully
log("BLPOP was unblocked by administrator");
}
}Why this works
A client library that is aware of Redis's push messages can catch this as a specific type of error, allowing the application to differentiate between a normal timeout and a forced unblocking.
Fix 2
No action needed for simple cases
WHEN If the client will simply retry the operation
// The client will likely just re-enter a loop
while (true) {
// This will just loop again if UNBLOCKED is received
redis.blpop("mylist", 0);
}Why this works
For many simple worker patterns, being unblocked is not a critical failure. The client can often just retry the blocking operation.
✕ Treat this as a fatal error
This is an operational signal, not a software bug. It means an external actor (or a configured timeout) has interrupted the command. Your application should be resilient to this.
Blocking commands and client interaction loop.
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev