Operaciones diferidas

Muchas operaciones del kernel son DEFERRED: el kernel acepta el pedido, devuelve un executionId y completa el trabajo después, cuando se procesan los efectos. Es el caso de InitiateTransaction → … → ExecuteTransaction (ver la historia de Transacciones) y de la creación de tenants. Por eso el CLI espera por defecto: lanza la operación y consulta la ejecución hasta que llega a un estado terminal.

--detach y execution wait

transaction execute y tenant create aceptan --detach: imprimen el resultado inicial (con execution-id) y vuelven sin esperar. Para retomar:

octopus execution wait <execution-id> --timeout 2m

execution wait usa el mismo motor de polling. execution get muestra el estado actual sin esperar. Si la espera se corta, el CLI imprime por stderr el comando para reanudarla (octopus execution wait <id>).

El motor de espera

Vive en internal/waiter y consulta RetrieveExecution:

Parámetro	Valor
Intervalo	1 s (fijo; no hay flag)
Timeout	60 s por defecto; --timeout en transaction execute y execution wait
Salida	spinner y pasos por stderr; silencioso con -o json

tenant create no tiene --timeout: usa los 60 s. apply espera solo los recursos de tipo Transaction (cada 500 ms, hasta 120 s); el resto de los tipos son inmediatos.

Estados terminales

El polling termina en SUCCEEDED, FAILED_FINAL, FAILED_RETRYABLE o CANCELLED. Cualquier otro estado sigue esperando.

• FAILED_FINAL y FAILED_RETRYABLE hacen que el comando devuelva error (código de salida 1).
• CANCELLED termina sin error.
• Si se agota el timeout, el comando falla con timed out after … (código de salida 1) y el CLI deja de esperar. Para volver a esperar la misma ejecución, execution wait <execution-id>.