Skip to content
Last updated

Asynchronous Operations

Some MoreLogin operations accept work before the underlying browser, Cloud Phone, file, application, or RPA execution reaches its final state. A successful submission response means the request was accepted; it does not always mean the requested state has already been reached.

Client state model

StateMeaningClient action
SubmittedThe API accepted the command or created a taskSave returned IDs and requestId; do not immediately submit the same write again
Pending or runningThe downstream operation is still progressingPoll the documented status/result endpoint with increasing intervals
SucceededThe target resource or task reached its successful terminal stateStop polling and continue the workflow
FailedThe status/result endpoint reports failure or a terminal business errorStop automatic retries; retain IDs, failure details, and requestId
Unknown outcomeThe write timed out or the connection closed without a usable responseQuery current resource/task state before deciding whether to retry

Polling rules

  • Start around 1 second, then increase the interval to 2, 4, 8 seconds, capped at 15–30 seconds.
  • Apply jitter so concurrent clients do not poll at the same instant.
  • Stop on a documented terminal state; do not poll indefinitely.
  • Treat data: null as pending only when the endpoint explicitly documents that behavior.
  • A transport timeout on a write is not proof of failure.

Documented workflows

WorkflowSubmit operationObservation operationTerminal state
Cloud browser start/stopPOST /cloudbrowser/start or /cloudbrowser/stopPOST /cloudbrowser/pageRuntime reaches the intended state or disappears after stop
Cloud Phone powerPOST /cloudphone/powerOn or /cloudphone/powerOffPOST /cloudphone/pageenvStatus=4 powered on or envStatus=2 powered off; 1 is creation failure
Cloud Phone file uploadUpload to the signed URL, then POST /cloudphone/uploadFilePOST /cloudphone/uploadFileResultstatus=1 success or status=2 failure; data: null and status=0 are pending
Cloud Phone downloadPOST /cloudphone/downloadPOST /cloudphone/download/resultstatus=20 success, 30 failure, or 40 cancelled; 10 is running
Application installationPOST /cloudphone/app/installPOST /cloudphone/app/installedListRequested package appears in the installed-app list
RPA schedule/executionPOST /cloudphone/rpa/task/save or /onceTask/savePOST /cloudphone/rpa/task/page, /subTask/page, and /subTask/detail/{id}taskState=2 completed or 3 cancelled; inspect handleResult (0 failed, 1 succeeded)
Live streamingPOST /cloudphone/live/start or /live/endPOST /cloudphone/live/statusStatus confirms streaming started or stopped
Cloud storage uploadPOST /cloudstorage/upload/init, followed by object-store PUTPOST /cloudstorage/upload/complete after every required PUT succeedsCompletion response succeeds; never call complete before object upload succeeds

Local API equivalents use the /api prefix where documented. See the Endpoint Retry and Completion Matrix for operation-by-operation guidance.

Timeout recovery example

try:
    submit_operation()
except TimeoutError:
    # The write may already have succeeded.
    current = query_current_state()
    if current.is_terminal_success:
        pass
    elif current.is_pending:
        poll_until_terminal()
    else:
        decide_whether_retry_is_safe(current)

The public API does not currently define a general idempotency-key header. Resource IDs, task IDs, state queries, and requestId are therefore essential to safe recovery.