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

TASK
Create a real team, then simulate a route that renames it by calling
HSET on team:{id} with a new name field -- WITHOUT updating
team:by_name. Show, with real code, that the old name still resolves
via the secondary index while the new name does not, and explain what
a real user-facing symptom of this bug would look like.

SOLUTION

Creating a real team, complete with its own secondary-index entry,
then simulating an incomplete "rename" route that only touches the
main hash:

  team_id = await r.incr("team:next_id")
  await r.hset(f"team:{team_id}", mapping={"name": "Wanderers FC",
                                            "founded": 1900})
  await r.hset("team:by_name", "Wanderers FC", team_id)

  # the buggy rename -- updates the record, forgets the index
  await r.hset(f"team:{team_id}", mapping={"name": "Wanderers United"})

Checking all three real sources of truth afterward:

  real team record now says:
    {'name': 'Wanderers United', 'founded': '1900'}

  lookup via OLD name 'Wanderers FC'     -> 1
  lookup via NEW name 'Wanderers United' -> None

The team's own real record correctly reflects the rename -- its name
field genuinely says "Wanderers United" now. But the secondary index
tells a completely different, inconsistent story: searching by the
team's own current, correct name returns nothing at all, while
searching by a name the team no longer has still resolves successfully
to the exact same team_id.

The real, user-facing symptom this would produce is genuinely
confusing rather than an obvious crash. Any feature built on top of
team:by_name -- for instance, the create-team route from earlier in
this chapter, which checks the index before creating a new team --
would now let someone create a brand-new team also named "Wanderers
United," since the index has no idea that name is already taken by
team_id 1 under its new name. Meanwhile, a search feature built the
same way would let a user find the team by typing its old, outdated
name, but report "no results" if they typed its real, current name --
exactly backwards from what anyone would expect. None of this throws
an error anywhere; it just quietly returns wrong, stale answers,
which is a genuinely harder class of bug to notice and diagnose than
one that crashes loudly.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the real stale-index bug with actual code, confirms the
exact inverted behavior (old name still works, new name doesn't) with
real output, and traces a concrete, realistic downstream symptom --
silent duplicate-creation and backwards search results -- rather than
just stating abstractly that "the index could go stale."