Saltar al contenido

Operaciones asíncronas

Algunas operaciones de MoreLogin aceptan el trabajo antes de que el navegador, Cloud Phone, archivo, aplicación o ejecución de RPA subyacente alcance su estado final. Una respuesta de envío correcta significa que la petición se aceptó; no siempre significa que el estado solicitado ya se haya alcanzado.

Modelo de estados del cliente

EstadoSignificadoAcción del cliente
EnviadoLa API aceptó el comando o creó una tareaGuarda los ID devueltos y requestId; no reenvíes de inmediato la misma escritura
Pendiente o en cursoLa operación posterior sigue avanzandoConsulta el endpoint documentado de estado/resultado con intervalos crecientes
CorrectoEl recurso o la tarea alcanzó su estado terminal de éxitoDeja de consultar y continúa el flujo
FallidoEl endpoint de estado/resultado informa un fallo o un error de negocio terminalDetén los reintentos automáticos; conserva los ID, los detalles del fallo y requestId
Resultado desconocidoLa escritura expiró o la conexión se cerró sin una respuesta utilizableConsulta el estado actual del recurso o la tarea antes de decidir si reintentas

Reglas de consulta periódica

  • Empieza sobre 1 segundo y aumenta el intervalo a 2, 4 y 8 segundos, con un tope de 15–30 segundos.
  • Aplica jitter para que varios clientes no consulten en el mismo instante.
  • Detente en un estado terminal documentado; no consultes indefinidamente.
  • Interpreta data: null como pendiente solo cuando el endpoint documente ese comportamiento explícitamente.
  • Un tiempo de espera de transporte en una escritura no es prueba de fallo.

Flujos documentados

FlujoOperación de envíoOperación de observaciónEstado terminal
Inicio/parada del cloud browserPOST /cloudbrowser/start o /cloudbrowser/stopPOST /cloudbrowser/pageEl runtime alcanza el estado previsto o desaparece tras la parada
Encendido del Cloud PhonePOST /cloudphone/powerOn o /cloudphone/powerOffPOST /cloudphone/pageenvStatus=4 encendido o envStatus=2 apagado; 1 es fallo de creación
Subida de archivos al Cloud PhoneSube a la URL firmada y luego POST /cloudphone/uploadFilePOST /cloudphone/uploadFileResultstatus=1 correcto o status=2 fallido; data: null y status=0 son pendientes
Descarga del Cloud PhonePOST /cloudphone/downloadPOST /cloudphone/download/resultstatus=20 correcto, 30 fallido o 40 cancelado; 10 es en curso
Instalación de aplicacionesPOST /cloudphone/app/installPOST /cloudphone/app/installedListEl paquete solicitado aparece en la lista de aplicaciones instaladas
Programación/ejecución de RPAPOST /cloudphone/rpa/task/save o /onceTask/savePOST /cloudphone/rpa/task/page, /subTask/page y /subTask/detail/{id}taskState=2 completado o 3 cancelado; revisa handleResult (0 fallido, 1 correcto)
Transmisión en directoPOST /cloudphone/live/start o /live/endPOST /cloudphone/live/statusEl estado confirma que la transmisión empezó o se detuvo
Subida a cloud storagePOST /cloudstorage/upload/init, seguido del PUT al almacén de objetosPOST /cloudstorage/upload/complete después de que cada PUT necesario tenga éxitoLa respuesta de finalización es correcta; nunca llames a complete antes de que la subida del objeto tenga éxito

Los equivalentes de la Local API usan el prefijo /api donde está documentado. Consulta la Matriz de reintentos y finalización de endpoints para la guía operación por operación.

Ejemplo de recuperación tras un tiempo de espera

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)

La API pública no define actualmente una cabecera general de clave de idempotencia. Por eso los ID de recurso, los ID de tarea, las consultas de estado y requestId son esenciales para una recuperación segura.