Guía de la versión preliminar · 0.1.0

Seguir los trabajos hasta un resultado confirmado

Lee el progreso real, distingue espera y fallo, y contrasta cancelaciones, reintentos y comandos inciertos sin duplicar trabajo.

La referencia de la API está en inglés.

Abre la tarea responsable del trabajo

Los análisis, revisiones de Advisor y mantenimiento de analizadores se ejecutan como trabajos. Abre Jobs, encuentra la tarea iniciada y consulta progreso, enlace al resultado y acciones disponibles. Comprueba tipo, proyecto u operación e identidad antes de cancelar o reintentar.

El resumen compacto agrupa recuentos generales por estado y tipo. Búsqueda y filtros reducen la lista sin cambiar esos totales. Así puedes encontrar una tarea sin confundir una lista filtrada con todo el historial de la instalación.

En la primera carga aparecen Loading job history y guiones en los recuentos no disponibles. No jobs yet y los ceros solo aparecen tras una lectura vacía correcta. History unavailable indica un fallo de lectura. Después de cargar, una recarga fallida conserva el historial y comunica el error; usa Refresh para contrastarlo con el estado persistido.

Lee el estado antes que el tiempo transcurrido

Un trabajo de análisis terminado no implica un control aprobado. Una comprobación terminada del resultado de caché no convierte la preparación original fallida en un trabajo correcto. Sigue el enlace al análisis, proveedor o estado de datos correspondiente.

Un reintento puede conservar la hora del primer inicio anterior. El tiempo mostrado puede incluir intentos anteriores y esperas intermedias. Un reintento encolado espera a un worker aunque conserve un heartbeat o actividad antiguos.

Interpreta el progreso real

Los trabajos de datos muestran etapa, componente y posición actuales del actualizador, última actividad y bytes cuando la fuente aporta un total. Verificación y activación no siempre tienen totales medibles. Un indicador indeterminado significa actividad sin porcentaje general ni estimación de finalización fiables.

Descarga, verificación de datos candidatos, activación y guardado del comprobante son partes de una preparación. No reciben cada una un plazo general nuevo. Recargar, reiniciar un worker o reintentar trabajo emitido no reinicia el presupuesto persistido.

Si aparece Work processing unavailable, los trabajos encolados siguen persistidos. Desde la copia del producto, usa el comando de inicio admitido:

make up

Espera a que el worker esté sano y recarga el trabajo existente. Si la actividad sigue obsoleta, inspecciona los detalles seguros y la salida de make logs. No elimines un analizador ni recrees la base para que un indicador parezca sano.

Solicita cancelación y espera la limpieza

Usa Cancel sobre el trabajo exacto cuando esté disponible. Primero se persiste la solicitud, luego se espera la limpieza de procesos y el comprobante final. Cerrar navegador, panel de progreso o editor no realiza esta acción.

La cancelación puede coincidir con la finalización. En preparación deja de estar disponible al alcanzar la activación o confirmación y no deshace una generación verificada ya activada. En Advisor remoto no retira contenido recibido por el destino. Lee el resultado final y el recurso actual sin suponer que se revirtieron todos los efectos.

En un lote multirraíz del editor, cancelar el trabajo actual deja sin iniciar las raíces posteriores. Cada raíz ya iniciada conserva su resultado. Un resultado incierto también detiene los siguientes envíos para que el lote no avance sin conocer el anterior.

Reintenta solo cuando el trabajo lo ofrezca

Usa Retry únicamente en un trabajo final apto que muestre la acción. Un fallo puede indicar bloqueo u otra recuperación. No vuelvas a enviar el mismo trabajo mientras el original espere, se ejecute o se cancele.

Una preparación cuyo plazo emitido ha vencido no obtiene tiempo al repetir el comando. Inspecciona el resultado e inicia una nueva preparación explícita cuando el flujo lo ofrezca. Retry verification comprueba un objetivo de caché sin cambios; no descarga bytes sustitutivos ni repara datos inválidos.

Una publicación incierta puede ofrecer Check cache outcome. Inicia un trabajo separado de solo lectura con su límite de quince minutos. No descarga, activa, revierte ni purga datos. La preparación original sigue fallida aunque la comprobación establezca que publicó correctamente. La preparación actual de los analizadores determina si puede iniciarse un análisis.

Retoma el trabajo tras desconectarte

Conserva las identidades exactas de trabajo y comando cuando la interfaz las proporcione. Reabre Jobs y recarga el mismo recurso tras reconectar. Una fila activa ausente, un timeout del cliente o HTTP 202 no establecen resultado final: 202 significa comando aceptado.

Los clientes API también deben conservar la clave de idempotencia donde se exija. Admite de 8 a 160 caracteres ASCII: letras, cifras, puntos, guiones bajos, dos puntos o guiones, comenzando por letra o cifra. Una clave vincula un comando exacto; reutilizarla con contenido diferente puede producir conflicto.

Después de un timeout, contrasta el comando original antes de crear otra clave. El header se exige en rutas concretas, no en cada POST. Las acciones masivas lo requieren para triage, no para todos los cambios de ciclo de vida. Consulta la operación exacta antes de construir la solicitud.

Continúa con recuperación para resultados inciertos, preparación de analizadores para disponibilidad, o arquitectura de trabajos y evidencias para relacionar admisión, ejecución y publicación de evidencia.