Ejecuciones y evidencia
Sigue una ejecución hasta que termine, lee su resultado y sus Step Actions, y obtén enlaces de evidencia de corta duración.
run.trigger pone ejecuciones en cola y responde al momento. Sigue cada runId devuelto con run.get, lee lo que hizo el agente con run.step_actions y obtén la evidencia que respalda el resultado de cada paso con run.evidence.
Seguir una ejecución con un cursor
La primera llamada a run.get solo necesita el id de la ejecución. Responde al momento:
1{2 "runId": "jh7examplerunid"3}Guarda el cursor numérico de la respuesta. Para esperar un cambio, envía el id de la ejecución, ese cursor y waitMs:
1{2 "runId": "jh7examplerunid",3 "cursor": 42,4 "waitMs": 250005}La solicitud responde en cuanto la ejecución cambia (su cursor aumenta) o llega a un estado final. waitMs puede ir de 0 a 25000 milisegundos; los valores mayores se tratan como 25000. Si no cambió nada en ese tiempo, la respuesta trae timedOut: true. No es un error: vuelve a enviar el mismo cursor o deja de esperar.
Los estados finales son passed, failed, couldnt_start y cancelled.
Qué devuelve run.get
| Campo | Qué contiene |
|---|---|
status | El resultado de la ejecución (consulta la tabla de abajo). |
flaky | true cuando la ejecución se superó pero un paso necesitó un reintento. |
progress | Pasos { completed, total }. |
steps | Una entrada por paso y plataforma: index, platform, outcome (el paso tal como está escrito), state, result y, cuando se conocen, failureCategory, flaky y retryCount. |
createdResources | Las cuentas, bandejas de entrada, números de teléfono y archivos que creó la ejecución, cada uno con su label, su identifier (una dirección, un número o un nombre de usuario, nunca un secreto), su stepIndex y su estado de limpieza (cleanup). |
evidence.available | Si run.evidence ya tiene algo que devolver. |
next | Una sugerencia sobre qué hacer a continuación. |
cursor, timedOut | Para la espera larga, como se explica arriba. |
También incluye el resumen de la ejecución que devuelve run.list: runId, projectId, testCaseId, testCaseName, platforms, environment, trigger (rama, PR, commit), planGroupRunId, startedAt y completedAt.
Estado de la ejecución
status usa los mismos resultados de ejecución que el panel:
status | Panel | Significado |
|---|---|---|
queued | Queued | Esperando a que quede libre un runner. |
running | Running | En curso. |
passed | Passed | Todos los pasos alcanzaron su resultado esperado y cada Final check lo corrobora. Revisa flaky. |
failed | Failed | Un paso no alcanzó su resultado esperado, o el agente no pudo demostrar que lo alcanzó. La explanation de cada paso fallido indica el motivo. |
couldnt_start | Couldn't start | No se pudo probar el entorno, así que no se ejecutó ningún paso. No se factura. |
cancelled | Cancelled | Alguien detuvo la ejecución. |
Si usas las ejecuciones como control en tu CI, considera superado solo passed. Las ejecuciones guardadas antes de este cambio con un resultado que no se pudo demostrar se devuelven como failed, con su motivo.
Estado y resultado del paso
Cada paso tiene un state: not_run (todavía no se ha llegado a él, o la ejecución se detuvo o no pudo empezar antes), running, finished o cancelled. Solo un paso terminado tiene result:
result | Panel | Significado |
|---|---|---|
passed | Passed | El paso alcanzó su resultado esperado. |
failed | Failed | El paso no alcanzó su resultado esperado, o el agente no pudo demostrar que lo alcanzó. |
null | El paso no ha terminado. |
Cuando se conoce la causa, failureCategory es app_bug, test_flaky, environment, test_error, runner o unknown. runner significa que algo falló del lado de Autonomy, por ejemplo que el modelo de IA no estaba disponible o que el navegador del runner se detuvo. Autonomy vuelve a ejecutar esa ejecución una vez de forma automática; si vuelve a fallar, queda en failed con una etiqueta Runner problem en el panel, y esos intentos no se facturan. Un paso que se quedó sin tiempo es environment, no runner.
next
next es un consejo, nunca la autoridad. Decide según status y steps.
next | Cuándo |
|---|---|
wait | La ejecución está en queued o running. |
evidence | La ejecución está en failed, o en passed con flaky: true. |
retry | La ejecución está en couldnt_start. |
none | En cualquier otro caso. |
Leer las Step Actions
run.step_actions lista todo lo que hizo el agente para alcanzar el resultado esperado de cada paso, ordenado por el momento en que empezó cada acción:
1{2 "runId": "jh7examplerunid",3 "stepIndex": 0,4 "limit": 1005}Cada elemento tiene actionId, stepIndex (null para el trabajo de toda la ejecución, como la preparación y la limpieza), platform, kind, label, summary y detail opcionales, outcome (running, ok o error), startedAt y endedAt. kind es uno de estos:
tool: una acción sobre la app, la bandeja de entrada o el teléfono.final_check: la comprobación nueva del producto con la que debe coincidir el resultado del paso.cleanup: la eliminación de lo que creó la ejecución.note: algo que el agente anotó por el camino.
Los valores que la ejecución creó o recibió se muestran tal como eran; los valores que guardaste como secretos se enmascaran y nunca aparecen.
Cada respuesta es una instantánea, y su cursor recorre solo esa instantánea. Las acciones pueden llegar tarde con una hora de inicio anterior, así que el cursor no sirve para seguir una ejecución en directo. Todas las respuestas incluyen runCursor, el mismo contador que el cursor de run.get. Mientras la ejecución está en curso, y después de que termine mientras se sigue informando de la limpieza, vuelve a leer desde el principio cada vez que cambie runCursor. Si no ha cambiado desde tu última lectura completa, no hay nada nuevo.
Obtener la evidencia
Llama a run.evidence con runId y, opcionalmente, un step numérico:
1{2 "runId": "jh7examplerunid",3 "step": 14}La respuesta es { run: { runId, status }, steps }, con una entrada por cada paso que se ejecutó:
| Campo | Qué contiene |
|---|---|
stepIndex, platform | Qué paso es. |
outcome | El resultado esperado del paso tal como está escrito. |
result | passed o failed. |
explanation | Una línea sobre lo que muestra la evidencia, o sobre por qué falló el paso. |
failureCategory | Cuando se conoce: app_bug, test_flaky, environment, test_error, runner o unknown. |
finalCheck | { agrees, detail }: si el Final check coincide con el resultado. |
media | Capturas, fotogramas y vídeo, cada uno con una url firmada y expiresAt. |
durationMs | Cuánto tardó el paso. |
La evidencia nunca incluye nombres de modelos de IA ni de proveedores, prompts, cifras de tokens o de coste, errores internos ni datos de pantalla sin procesar.
Enlaces de medios firmados
Cada url de medios tiene este aspecto:
GET https://api.autonomyqa.com/api/v1/evidence/<id>?kind=<screenshot|frame|video>&exp=<epoch-ms>&sig=<signature>Un enlace funciona durante 15 minutos y no necesita credencial Bearer: la firma lleva el permiso. Un enlace válido redirige (302) al archivo. Un enlace no válido o caducado devuelve 403 con "The evidence link is invalid or has expired."; si falta el medio, devuelve 404. Para obtener enlaces nuevos, vuelve a llamar a run.evidence. No modifiques la cadena de consulta.
Valores del entorno y secretos
Los entornos guardan valores con nombre que los pasos usan como {{env.NAME}}, en el texto del resultado esperado o en el value, la address o el number de un adjunto. Cada ejecución los rellena desde el entorno en el que se ejecuta. Aquí un paso usa un código de invitación guardado en el entorno:
1{2 "id": "join",3 "text": "The grower joins the cooperative with the invite code",4 "attachments": [5 {6 "id": "invite-code",7 "kind": "data",8 "label": "Invite code",9 "value": "{{env.COOP_INVITE_CODE}}",10 "exact": true11 }12 ]13}Un valor marcado como secreto es de solo escritura. environment.list y environment.get solo devuelven los nombres de los valores (runtimeValueNames), nunca los valores. Cuando un runner toma la ejecución, Autonomy le envía los valores secretos a los que hacen referencia los pasos. Se rellenan por referencia, así que el agente nunca los ve, y se enmascaran en las Step Actions, la evidencia y los registros. La API nunca devuelve un valor secreto.
Para un objetivo de API nuevo, run.trigger puede llevar valores en targets.api.runtimeValues. Consulta Entornos para gestionar los valores en el panel.
¿No lo encontraste?