Exercise 1: Tracing Step 6 in Detail — Possible Solution
====================================================================

WHAT THE BROWSER RECEIVES
------------------------------
mark_used commits the item's status change (status='used', used_at set, expiry_date cleared to None) and immediately returns the updated item as the response. Priya's browser receives that confirmation right away, without waiting for anything else to happen first.

WHAT HAPPENS AFTERWARD, IN THE BACKGROUND
------------------------------
Only after that response has already been sent does background_tasks.add_task(log_usage, ...) actually run - log_usage writes a new UsageLog entry recording that this item was marked used. This happens entirely after the point where Priya's browser already has its answer, with no further delay added to what she experienced.

WHY THE BACKGROUND PORTION NEEDS ITS OWN SESSION
------------------------------
By the time log_usage actually executes, the request that originally called mark_used is fully finished, and get_db's own generator has already closed that request's session in its finally block. log_usage can't reuse a session that no longer exists in a usable state - it has to open its own fresh SessionLocal() specifically because the original session's own lifecycle already ended before this background work even started.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly separates what happens before the response (the actual status update) from what happens after it (the background log write), and correctly explains why the background portion needs its own session - the original request's session is already closed by the time that background work runs.