An engineer's Python service triggers a bulk rollout through a network controller that can run for several minutes per device. The controller accepts each request with HTTP 202 and returns a task identifier, and the script must report the final outcome while keeping worker processes free and submitting the job only once. Which API consumption pattern should the script use to follow the rollout to completion?
Select an answer to reveal the explanation.
Short Explanation
HTTP 202 hands you a claim ticket and lets the connection go, so you're free to come back for the result later. Polling the task endpoint with growing gaps is how you collect on that ticket without hogging a worker. Read the final state before you report success.
Full Explanation
A 202 Accepted response means the server has taken responsibility for the work and will report progress elsewhere, so the pattern that fits is task polling: store the task identifier, query its status endpoint on a schedule with growing delays, stop once the task reaches a completed or failed state, and fetch the final result from the location the controller reports. Keeping the original HTTP connection open is the synchronous long-poll approach, and it pins a worker for the whole rollout while intermediaries time out the idle socket. Resubmitting the same request treats every poll as a fresh job, which risks duplicate rollouts because the call is not idempotent. Waiting a fixed interval is a common shortcut, but job duration varies with device count and failures, so the script either reads too early or hides an error that finished long before the timer. Exam caveat: controllers differ in how long they retain task results, so read the final status promptly. Practical check: print the task identifier, the poll interval and the final state on one log line during a test run.