DISCARD in Redis

You have a pipeline of Redis commands bundled inside MULTI… but suddenly you realize the logic is wrong or you’re about to write bad data. Without an escape hatch, you’d be forced to execute the faulty transaction and then clean up the mess. That’s exactly the pain DISCARD solves: it’s your undo button for an in‑flight Redis transaction.

The problem this lesson solves

When you issue MULTI, Redis queues every subsequent command without executing them until EXEC is called. This is powerful for batching atomic operations, but it also means a mistake—like hitting the wrong key, queuing an incompatible type, or wanting to abort due to application logic—will commit garbage unless you have a way to cancel. Waiting for EXEC to fail partway through can leave your data in an inconsistent state. DISCARD gives you the ability to discard the entire queued transaction cleanly, returning your connection to normal mode without applying any changes.

Core concept / mental model

Think of MULTI as starting a “journal” page. Every command you write after MULTI is a line on that page. EXEC says “publish the whole page” to your dataset. DISCARD says “tear out the page and throw it away”—no commands get executed, the transaction is aborted, and the queue is emptied.

• The transaction context is the period between MULTI and either DISCARD or EXEC.
• While inside a transaction, every command queues but does not execute. The server replies with QUEUED (not the actual result).
• DISCARD immediately exits the transaction context, discarding all queued commands.

Blockquote pro tip: DISCARD does not return a status about individual queued commands—it simply flushes the entire queue. The command itself always replies with OK.

How it works step by step

1. Start the transaction: Send MULTI. Redis switches into transaction mode.
2. Queue commands: Issue one or more commands (e.g., SET, INCR, LPUSH). Each returns QUEUED.
3. Decide to abort: When you detect a problem (or simply decide not to proceed), send DISCARD.
4. Redis reacts: The server discards the queue, exits transaction mode, and replies with OK.
5. Back to normal: Subsequent commands execute immediately (not queued).

Key behavioral rules

• DISCARD can only be called after MULTI and before EXEC.
• If you call DISCARD outside a transaction, Redis returns an error: ERR DISCARD without MULTI.
• Discarding a transaction releases any keys that were being watched by WATCH (if used). However, DISCARD does not reset the watch—you must explicitly UNWATCH if you want to reuse a watched key later.

Hands-on walkthrough

Let’s simulate a scenario where you start a transaction, queue some commands, then decide to cancel.

Example 1: Basic discard

# Connect to Redis CLI
redis-cli

# Step 1: Start transaction
MULTI
# Output: OK

# Step 2: Queue two SET commands
SET mykey1 "hello"
# Output: QUEUED

SET mykey2 "world"
# Output: QUEUED

# Step 3: Abort the transaction
DISCARD
# Output: OK

# Step 4: Verify nothing was written
GET mykey1
# Output: (nil)

Example 2: Discard in Python (with redis-py)

import redis

r = redis.Redis(decode_responses=True)

# Start transaction
pipe = r.pipeline(transaction=True)
pipe.multi()

pipe.set("user:10:name", "Alice")
pipe.incr("user:10:visits")

# Oops! Wrong user? Discard.
pipe.discard()

# Confirm no keys were created
print(r.exists("user:10:name"))  # 0 (false)
print(r.exists("user:10:visits"))  # 0 (false)

Example 3: Conditional discard based on data

import redis

r = redis.Redis(decode_responses=True)

# We only want to SET if a specific condition holds (simulate)
should_proceed = False  # Imagine this comes from external logic

pipe = r.pipeline()
pipe.multi()
pipe.set("config:mode", "dark")
pipe.set("config:timeout", "60")

if not should_proceed:
    pipe.discard()
    print("Transaction discarded due to condition")
else:
    pipe.execute()
    print("Transaction executed")

Expected output (no keys written):

Transaction discarded due to condition

Compare options / when to choose what

Choose DISCARD when you know you don’t want any of the queued operations. If you only want to stop watching keys, use UNWATCH.

Troubleshooting & edge cases

Common mistake 1: Calling DISCARD without MULTI

redis-cli DISCARD
# (error) ERR DISCARD without MULTI

Fix: Ensure you have a prior MULTI on the same connection. Use MULTI first.

Common mistake 2: Attempting to discard after EXEC

MULTI
SET x 1
EXEC
# OK
DISCARD
# (error) ERR DISCARD without MULTI

Fix: EXEC ends the transaction, so DISCARD becomes invalid. Only discard before calling EXEC.

Common mistake 3: Forgetting that WATCH is not reset by DISCARD

WATCH mykey
MULTI
SET mykey 999
DISCARD
# WATCH is still active on mykey!

Fix: If you plan to retry the transaction later, explicitly UNWATCH to avoid stale watches causing unexpected failures.

Edge case: Network timeout during transaction

If the connection drops while commands are queued, Redis automatically discards the transaction—no action needed. This is safe, but you lose the commands.

What you learned & what's next

You now understand: - How DISCARD cancels a Redis transaction in progress. - The precise step: MULTI → queue commands → DISCARD → queue cleared. - How to use it in a Python client to conditionally abort. - The difference between DISCARD, EXEC, and UNWATCH.

Next: Learn how to watch keys for optimistic locking with WATCH. This lets you detect changes during a transaction and retry or discard based on changing data—a critical pattern for building reliable counters and reservation systems.

Practice by writing a small script that starts a transaction, reads a key (not inside the transaction), decides based on its value whether to discard or execute, and verifies no keys were changed after discard.