Exercise 1: The General Rule for When async def Helps — Possible Solution
====================================================================

THE GENERAL RULE
------------------------------
async def genuinely helps a route when that route waits on something slow and external, most commonly a network call - during that wait, control can return to the event loop, which uses the idle time to make progress on other requests. A route that only touches something fast and local gains little benefit from being written as async, since there's very little meaningful idle time for the event loop to reclaim.

WHY get_alerts IS STILL A PLAIN def
------------------------------
get_alerts only queries the local SQLite database - an operation that completes almost immediately, with essentially no meaningful waiting period the way an external network call has. Writing it as async def wouldn't create any real benefit, since there's barely any idle time during the query for the event loop to usefully reclaim.

WHY THIS DOESN'T CONTRADICT "ASYNC-NATIVE"
------------------------------
Being "async-native" means FastAPI supports async naturally when it's genuinely useful, not that every single route must be written as async regardless of whether it actually benefits. Using a plain def where async wouldn't help is consistent with that philosophy, not a departure from it - the framework simply doesn't force async everywhere it isn't warranted.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly states the general rule (async helps specifically when a route waits on something slow and external), correctly applies it to explain why get_alerts stays synchronous, and correctly explains why this is consistent with, not contrary to, the course's own "async-native" framing.