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

TASK
Run a real HGETALL against a team key that was never created at all --
not even accidentally, genuinely never written. Report the real
return value and its real Python type, and explain why this makes
the "reference to team:999" problem from this chapter even harder to
catch than it already looks.

SOLUTION

Running a real HGETALL against team:99999, a key that has genuinely
never been written to by anything:

  result = await r.hgetall("team:99999")

produces this real result:

  result: {}   type: dict

Redis doesn't raise an error, doesn't return None, and doesn't
distinguish this case from "a real team that happens to have zero
fields" -- it returns a genuinely empty dict either way, exactly the
same value Python code would get back from a perfectly successful
call that simply found nothing to return.

This makes the chapter's own missing-team-reference problem worse
than it first looks. Imagine a real route handler that, given a
fixture, tries to look up the away team to display its name:

  away_team = await r.hgetall(f"team:{fixture['away_team_id']}")
  print(away_team.get("name"))   # returns None, no crash

If away_team_id points at a genuinely nonexistent team (like this
chapter's own team:999 example), that lookup doesn't fail loudly --
it just quietly returns an empty dict, and away_team.get("name")
quietly returns None. Nothing here raises an exception, logs a
warning, or in any way distinguishes "this team was deleted or never
existed" from "this is a real, valid team object that simply has no
name field set yet." A developer would have to specifically think to
check for an empty dict and treat it as an error case -- there's no
structural signal from Redis itself pushing them toward that check,
the way a real SQL JOIN silently dropping a row, or a foreign key
constraint actively rejecting the bad write in the first place, both
would.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reports the real, verified empty-dict return value and its type,
then correctly traces how that specific behavior compounds the
chapter's own missing-foreign-key finding -- a lookup against a
nonexistent team doesn't fail, it silently succeeds with nothing
useful in it, removing the one obvious signal (a crash) that might
otherwise have surfaced the underlying data problem.