Exercise 2: A Faster Flow, Under the Timeout — Possible Solution
====================================================================

THE MODIFIED FLOW
------------------------------
    def test_full_checkout_flow_faster():
        session = SessionStore()
        token = session.login("u1")
        time.sleep(0.03)   # faster browse
        items = browse_catalog(session, token)
        time.sleep(0.07)   # faster checkout, total delay now 0.10s
        return checkout(session, token, items)

RESULT
------------------------------
    Faster flow (0.10s total delay, under the 0.15s timeout): PASSED
      -> {'order_id': 'O1', 'items': ['item1', 'item2']}

WHY PASSING HERE DOESN'T MEAN THE RISK IS GONE
------------------------------
The underlying bug from the chapter was never really "the flow is
broken" - it's that checkout() has no safety margin once a real user
takes longer than SESSION_TIMEOUT_SECONDS to complete the flow. This
modified test happens to complete in 0.10s, comfortably under the
0.15s timeout, so it passes - but a real user who pauses to read a
product description, gets distracted, or has a slow connection could
easily take longer than that. A single passing e2e run at one
particular speed proves the flow CAN succeed under favorable timing;
it doesn't prove the system handles realistic variation in how long
real users actually take.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is the same insight Chapter 6's own flakiness section already
established from a different angle: a test's outcome depending on
timing that isn't explicitly controlled is a design smell, whether the
test happens to pass or fail on any given run. The real fix isn't
"make the e2e test fast enough to pass" - it's addressing the
underlying session-timeout design so a normal-speed user isn't at risk
of hitting it, and then testing that guarantee directly (for instance,
with a test that deliberately runs at various realistic speeds,
including slow ones, rather than a fixed happy-path duration).