Build a Resilient Concurrent Python CLI for Local-Service Lookups

Design a Python command-line tool that accepts a list of serial numbers, requests information for each one from an existing local service, and reports the results. Extend the tool to handle failures and then to issue requests concurrently with a thread pool. ### Constraints and Clarifications The service address, request route, and successful JSON shape are supplied by the environment and are not specified here. Do not invent an endpoint. For the practice interface, produce one result record per input occurrence, retaining the serial number and either a successful payload or a classified error. Keep final output in input order, even if concurrent requests finish in another order. These output conventions are explicit exercise assumptions. ### Part 1 — Retrieve Serial-Number Results Explain how the CLI accepts input, invokes the local service for each serial number, and aggregates successful responses. #### What This Part Should Cover - Input validation and separation of argument parsing, request logic, and output formatting. - A request function that retains the relationship between one serial number and its response. - A consistent result structure and behavior for empty input or repeated serial numbers. ### Part 2 — Handle Service and Response Failures Handle request timeouts, HTTP 500 responses, and invalid JSON without losing successful results from other requests. #### What This Part Should Cover - Separate error classifications for timeout, HTTP failure, and JSON parsing failure. - A finite request timeout and an explicit, bounded retry policy appropriate to the operation's semantics. - An aggregate result and exit-status policy that makes partial failure visible. ### Part 3 — Add Thread-Pool Concurrency Run requests concurrently and collect their results safely. #### What This Part Should Cover - A bounded number of concurrent requests and a mapping from each future to its input position. - Per-request exception handling and result aggregation that preserve input order. - Resource cleanup, shutdown behavior, and the effect of a slow or hung request. ```hint Preserve identity independently of completion order Two different requests can finish in the opposite order from submission. Keep the input position with the future so concurrency does not corrupt the report. ``` ### What a Strong Answer Covers The sequential, error-handling, and concurrent versions share a request/result contract. Partial failures remain visible, concurrency is bounded, and neither exception handling nor thread scheduling changes which result belongs to which serial-number occurrence. ### Follow-up Questions 1. How would you prevent a large input list from creating an equally large backlog of pending futures? 2. When is retrying an HTTP 500 safe, and what additional information is needed if the endpoint can produce side effects? 3. What should happen if a user interrupts the CLI while some requests have completed and others are still running?