Fetch and Cache Daily Stock Prices Across a Date Range

# Fetch and Cache Daily Stock Prices Across a Date Range Implement a Python function `solution(first_date, last_date)` that returns every available trading date in the inclusive range, together with that day's opening and closing prices. Both inputs are strings and must be parsed and validated. The assessment supplies an HTTP endpoint and response documentation. Your implementation must retrieve real data from that endpoint, return records ordered by date, avoid repeating an identical request when cached data is still valid, and handle request failure, timeout, malformed payloads, duplicate dates, and dates with no trading record. Each returned element has this exact form: ```text YYYY-MM-DD OPEN CLOSE ``` Prices use exactly two decimal places. For example, a valid result could contain `1928-02-07 200.00 203.00`. ### Constraints & Assumptions - `first_date` and `last_date` use the exact `YYYY-MM-DD` calendar format. - The inclusive range may contain weekends or holidays; omit dates for which the API returns no trading record. - The endpoint's documented pagination and symbol identity are provided during the assessment and must not be guessed. - A malformed caller date raises a validation error before any HTTP request. - The caller must receive an explicit failure if the required range cannot be assembled reliably; silently returning a partial range is not acceptable. ### Clarifying Questions to Ask - Is the endpoint queried once per date, once per page, or with a date-range filter? - What timeout, retry budget, and cache freshness policy are required? - May stale cached data be used when the endpoint is unavailable? - How are prices represented in the payload, and must decimal precision be preserved exactly? - What should happen if two response records claim the same date with different values? ### What a Strong Answer Covers - Strict date parsing, inclusive range validation, canonical request construction, and chronological output. - A bounded HTTP client with explicit connect and read timeouts, retry only for appropriate transient failures, and status validation. - Pagination or date-range traversal that proves the requested interval is complete rather than returning the first page only. - Schema validation for date, opening price, and closing price before a record enters the result. - Decimal-safe formatting, duplicate-date policy, non-trading dates, and rejection of contradictory or out-of-range data. - A cache keyed by every request parameter that affects the response, with expiration, bounded size, and safe concurrent access where needed. - Clear error propagation, test seams for the HTTP client and clock, and tests that do not depend on the live endpoint. ### Follow-up Questions 1. How would you prove that a successful HTTP response still contains every page needed for the date range? 2. What cache key prevents one stock, date interval, or API version from reusing another response? 3. When is retrying an HTTP failure safe, and how do you avoid multiplying traffic during an outage? 4. Why might binary floating point produce the wrong two-decimal display for a price? 5. How would two callers requesting overlapping ranges share useful cached work without returning incomplete data?