A network engineer automates a controller job that takes several minutes to finish. The endpoint answers in under two seconds with HTTP 202 and a task identifier, but the office firewall drops idle connections after 30 seconds. How should the script retrieve the finished result from this asynchronous job?
Select an answer to reveal the explanation.
Short Explanation
When you get a task ID, you can check back at intervals and read the result once the job is complete. You won’t have to keep a connection open through the firewall timeout, and retrying the submission won’t retrieve this task’s result. It’s like getting a deli ticket and checking when your number is called.
Full Explanation
The HTTP 202 response means the controller has accepted your request but has not finished the job; the returned task identifier lets you follow that work. Poll the task at a reasonable interval, following any documented guidance, and read the result once its status reports completion. This avoids keeping a connection open through the several-minute job and the firewall’s 30-second idle limit. Registering a callback URL can work when the API explicitly supports callback registration, but that support is not stated here; this interface gives you a task identifier to track. Waiting the documented typical run time and making one GET request may seem efficient, but a typical duration does not guarantee completion. The task could still be running, so that request would not confirm that the result is ready. Retrying submission with an idempotency key may prevent duplicate work when the API supports it, but it does not retrieve the result for the accepted task; you need to track its identifier. Exam caveat: pace and limit your polling according to API guidance rather than sending requests continuously. Practical check: consult the API documentation for the task-status and result fields, recommended polling interval, and terminal failure states.