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

TASK
Reproduce this chapter's own no-rollback finding with a genuinely
different failing command -- queue a real HSET against a key that
already holds a plain string (not a hash), sandwiched between two
valid SADD calls on a real Set, inside one MULTI/EXEC transaction.
Report whether the two valid SADD calls survive.

SOLUTION

Setting up a real plain string key and a real Set, then queuing three
commands in one real transaction -- a valid SADD, an invalid HSET
against the string key, and a second valid SADD:

  await r.set("plainstring:test", "hello")
  await r.sadd("realset:test", "member-a")

  async with r.pipeline(transaction=True) as pipe:
      pipe.sadd("realset:test", "member-b")            # valid
      pipe.hset("plainstring:test", "field", "value")  # INVALID
      pipe.sadd("realset:test", "member-c")            # valid
      results = await pipe.execute()

produces this real result:

  pipe.execute() raised: ResponseError
    Command #2 (HSET plainstring:test field value) of pipeline
    caused error: ('WRONGTYPE Operation against a key holding the
    wrong kind of value',)

  realset:test AFTER the failed transaction:
    {'member-a', 'member-b', 'member-c'}

Both real SADD calls survive. member-b and member-c both appear in
the final set alongside the original member-a, confirmed by a direct
SMEMBERS read taken after the transaction raised its own exception.
This is the exact same pattern as this chapter's own INCR example,
now reproduced with a completely different pair of commands (SADD
instead of INCR) and a completely different kind of type mismatch
(HSET against a string instead of INCR against a Set) -- confirming
the no-rollback behavior isn't specific to one command pair, it's a
real, general property of how MULTI/EXEC works in Redis.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the chapter's own finding with genuinely different
commands and a genuinely different type-mismatch error, confirming
with real, independently-verified evidence that both valid SADD calls
survived the transaction despite the middle command failing -- showing
the no-rollback behavior generalizes rather than being a quirk of the
specific INCR/Set example the chapter itself used.