Polling Azure Vision Read OCR until it completes

The polling boundary. The Azure Vision Read (OCR) API is asynchronous: you start an analysis, receive an operation_id, and then call get_read_result(operation_id) to fetch the current state. That method always returns immediately with a snapshot — it never blocks until the server finishes. The trap is believing the initial call itself can be made to wait; it cannot. Waiting is the caller's responsibility, which is why option C (removing operation_id) is wrong: without the operation identifier the client cannot locate the job at all, and removing it does nothing to make the call synchronous.

What actually gates completion. The ReadResult object returned by get_read_result carries a status property with values such as notStarted, running, succeeded, and failed. Checking that value (A) is the only way to know whether OCR output is safe to read — parsing analyze_result.read_results while status is running yields empty or partial lines. Option B is the distractor: read_operation_location is the URL of the operation resource captured when the read operation was submitted; its presence tells you nothing about progress. Polling a location string rather than the returned status is a classic misreading of the SDK.

Combining both. Status checking alone only samples once, and a loop alone without the status test would either spin forever or break on a fixed count. The correct pattern is a loop with a delay (D) that repeatedly calls get_read_result and exits when read_result.status (A) is no longer notStarted/running — exactly the pattern shown in the community example: while True: … if read_result.status not in ['notStarted', 'running']: break … time.sleep(1). Both A and D are therefore required, matching the two-point multi-select instruction.