Premier League Predictor: FastAPI & Redis — Chapter 3, Exercise 3
=====================================================================

TASK
Explain, in your own words, why a Python exception raised by
pipe.execute() cannot be safely treated as "this transaction had no
effect," using this chapter's own verified counter example as
evidence. What real, different question does the exception actually
answer?

SOLUTION

Treating pipe.execute() raising an exception as "nothing happened"
would be a reasonable assumption in a world built around SQL
transactions, where that really is what an exception from inside a
commit typically signals -- most relational libraries raise
specifically because the database itself refused to apply the change,
or because the client is about to roll everything back in response.
The exception, in that world, is the mechanism carrying the news that
the whole operation was undone.

This chapter's own verified counter example shows that assumption
doesn't transfer to Redis at all. The real transaction ran three
queued commands: a valid INCR, an invalid INCR against a Set (which
Redis rejected with a real WRONGTYPE error), and a second valid INCR.
pipe.execute() did genuinely raise a real Python exception -- but the
counter's own real value afterward was 12, not the original 10,
proving both valid INCR calls had already taken permanent effect by
the time that exception was raised. If "the exception means nothing
happened" were true, the counter would still have read 10. It didn't.

The real question pipe.execute() raising an exception actually
answers is much narrower: "did every command in this transaction
individually succeed?" It's reporting that at least one command
failed -- nothing more, and specifically nothing about whether any
other command in the same batch succeeded or failed, and nothing
about whether the store's own state changed as a result. Those are
two genuinely separate questions in Redis, where they're the same
question in a system with real rollback support. Because Redis
documents directly that it "does not support rollbacks," the correct
and safe interpretation of a caught exception here is "something in
this batch went wrong, but the other commands in it may well have
already taken effect" -- which is exactly the behavior this chapter's
own counter example, and this exercise's own independent SADD
reproduction, both demonstrated with real evidence rather than
assumption.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly distinguishes "at least one command failed" from
"nothing was committed" as two genuinely different claims, using the
chapter's own real counter-value evidence (10 -> 12, not 10 -> 10) to
prove the second claim is false even though the exception itself is
real, and states precisely what the exception does and doesn't tell
the caller.