A batch job retrieving wireless health for city branch IDs receives HTTP 404 for one identifier. What is the correct control flow for that resource hop?
Select an answer to reveal the explanation.
Short Explanation
A 404 says that address does not exist. Standing on the empty lot forever will not build the house. Close that item, log the ID, and move on if the batch allows skipping.
Full Explanation
HTTP 404 for one wireless-health identifier means that resource is not found at the requested URL. For a batch job over city branch IDs, the correct control flow is to stop that item, log the identifier for investigation, and continue only if batch policy is skip-item—not to retry the missing ID forever. Other IDs can still succeed; one bad key should not pin the whole job.
Looping GET on the same URL forever until the identifier spontaneously appears wastes budget on a non-existent resource. Treating 404 as a 503 and applying Retry-After without logging the ID misclassifies not-found as temporary unavailability and loses forensic value. Rewriting every remaining ID to an unrelated trivia endpoint abandons the health-retrieval goal and corrupts the batch.
Exam caveat: a 404 can also mean a wrong base path or API version for all IDs—if many 404s appear at once, verify the endpoint template before skip-item logic hides a systemic misconfiguration. Operational check: log each 404 branch ID, emit a per-item failure metric, continue remaining wireless-health GETs under skip-item policy, and page only if error rate exceeds the city’s batch threshold. Persist skip/fail results per branch ID so a later rerun can retry only unresolved identifiers after inventory is corrected. Never promote a batch as fully successful if skip-item policy left gaps—report partial completion to the wireless-health consumers.