Handle Failures Without Taking Down the Dashboard

error handling and status codes

Part of: Ship & Monitor an LLM App (Capstone)

A deployed endpoint fails in ways your laptop never showed you. The provider times out, you hit a rate limit, a caller sends garbage. An unhandled exception in a web route doesn't just fail that one request. It can crash the worker process that's serving other users' requests too. This lesson wraps the request path in defenses so one bad call degrades gracefully instead of taking the service down. Catch specific things, not everything Blanket except Exception hides real bugs. Catch the failure modes you actually expect and map each to the right response: Each branch returns the same shape (ok, status, plus either reply or error), so every caller handles success and failure the same way, whether it's the web route, the logger, or a test. That consistency keeps error handling from turning into a maze of special cases. Status codes carry meaning - 400 : the caller's fault (bad input). Don't retry without fixing the request. - 429 : you're being rate limited. Back off and retry later. - 502/504 : the upstream provider failed or timed out. Often safe to retry once. Picking the right code isn't pedantry. It's what lets a caller (or a monitoring system) react correctly without parsing you

Challenge: Classify the Failure