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

TASK
Point this chapter's own /health endpoint at a port with no Redis
instance listening at all, and run it for real. Report the exact real
exception type and message you get back, and explain what the
current /health endpoint's own code would actually do with it (hint:
nothing catches it).

SOLUTION

Pointing a real redis.asyncio.Redis client at a genuinely unused
port (nothing listening there at all) and calling .ping() on it
directly:

  r = redis.Redis(host="127.0.0.1", port=6399, decode_responses=True,
                   socket_connect_timeout=2)
  pong = await r.ping()

produces a real, unhandled exception rather than a graceful False or
None return:

  real exception type:    TimeoutError
  real exception message: Timeout connecting to server

This chapter's own /health endpoint code is:

  @app.get("/health")
  async def health():
      pong = await app.state.redis.ping()
      return {"status": "ok", "redis_ping": pong}

There's no try/except anywhere in it. If Redis is genuinely down when
a request hits this endpoint, the real TimeoutError raised by
.ping() propagates straight up out of the route function completely
unhandled. FastAPI's own default behavior for an unhandled exception
inside a route is to convert it into a generic 500 Internal Server
Error response -- so a real Redis outage would present to a client as
an opaque server error, with the specific, real, useful detail
("Timeout connecting to server") only visible in the server's own
logs, not in the response body a caller actually sees.

This is a genuine, real gap in the endpoint as written in this
chapter -- worth noticing now specifically because it's the very
first piece of Redis-calling code this course wrote, and every real
route built in later chapters inherits the identical risk unless it's
addressed directly. A more complete health check would wrap the
ping() call in a real try/except and return a deliberately
different, still-200-or-503 response describing the real failure,
rather than letting FastAPI's own generic 500 handler paper over
exactly what went wrong.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the real failure with actual code rather than assuming
what would happen, reports the genuine exception type and message
verbatim, and correctly traces that the current /health endpoint has
no exception handling at all, so a real outage becomes an opaque
FastAPI 500 rather than a clear, diagnosable response.