# Build a Resilient Chain of Clue-Driven HTTP Requests Implement or design a client that starts from one URL and follows a chain of HTTP responses. A successful JSON response may contain: - `next_url`, the URL for the next request; - `access_token`, a bearer token required by one or more later requests; and - `result`, which terminates the chain and must be returned. Some requests fail transiently. The client should retry retryable failures without duplicating unlimited work, carry a received bearer token only where policy allows it, and stop safely on malformed responses, loops, or an excessive chain length. ### Constraints & Assumptions - Treat timeouts, connection resets, HTTP 429, and HTTP 5xx as potentially retryable. - Treat other HTTP 4xx responses as terminal unless the response explicitly supplies a new authentication clue. - A maximum-attempt count, total deadline, and maximum-hop count are configurable. - Response bodies can be size-limited before parsing. ### Clarifying Questions to Ask - Can `next_url` change host, and which hosts may receive the bearer token? - Are requests always idempotent GETs? - Does a newer token replace the old one, and can a response intentionally clear it? - What output or audit information is required on failure? ### What a Strong Answer Covers - An explicit state machine for URL, token, hop count, and retry budget - Retry classification, backoff with jitter, and server-directed delays - Loop detection and resource limits - Token-origin validation and redacted logging - Testability through an injected HTTP transport and clock ### Follow-up Questions - What changes if one clue requires a non-idempotent POST? - How do you avoid leaking a token during a cross-origin redirect? - Should the retry budget be per hop or global? - How would you make a long-running chain resumable after process failure?