Higgsfield agotó la espera, pero mi imagen ya estaba hecha
Un tiempo de espera agotado en Higgsfield puede ocultar una imagen terminada y cobrada. Así recuperé la mía sin gastar otro crédito.
Timeout after 6m0s; last status "in_progress" era el mensaje que aparecía en pantalla.
El programa que ejecutaba la generación contabilizó la imagen como un fallo. No se había descargado nada. Desde mi lado, el trabajo parecía haberse quedado en nada.
Esa combinación es peligrosa porque hace que volver a generar parezca el siguiente paso lógico. El comando ha fallado, no hay ninguna imagen en el disco y la cola ya ha consumido seis minutos. Es fácil dar por hecho que Higgsfield nunca terminó el trabajo.
Esa suposición me habría costado otro crédito.
El trabajo no se había perdido. Higgsfield seguía procesándolo en el servidor. Terminó más tarde, la imagen completa estaba allí y el crédito original ya se había cobrado.
Había fallado el cliente que esperaba el resultado. No la generación en sí.
Una palabra ocultaba dos estados distintos
Mi programa había etiquetado el resultado como FAIL.
La etiqueta era útil desde el punto de vista técnico, pero demasiado amplia. Me decía que el comando no había completado la secuencia local prevista. No me decía por qué.
En este caso, el comando debía esperar a Higgsfield, recibir el resultado terminado y descargar la imagen. El límite de espera de seis minutos venció mientras el estado remoto seguía siendo in_progress. La descarga nunca llegó a producirse, así que el programa registró un fallo.
Pero agotar el tiempo de espera no canceló el trabajo del servidor. Higgsfield siguió trabajando.
Eso crea una separación incómoda entre lo que existe en local y lo que existe en remoto. Mi carpeta dice que falta la imagen. El servidor dice que el trabajo acabó terminándose. El registro de facturación se rige por el servidor, no por el hueco vacío de mi carpeta.
Si interpreto cada fallo local como una generación fallida, pago otra vez por un trabajo que ya está hecho.
Consulté el servidor antes de volver a generar
La recuperación empezó con una regla: todavía no volver a lanzar nada.
Consulté los 20 trabajos de generación más recientes:
generate list --size 20
El trabajo que había agotado el tiempo de espera estaba entre esos registros recientes. Había quedado huérfano desde el punto de vista del programa local. El comando que lo creó había dejado de esperar, pero el trabajo remoto había continuado sin que ese proceso local lo siguiera hasta el final.
Encontrar un trabajo terminado en la lista reciente todavía no me decía qué archivo descargado correspondía a la imagen que faltaba. Tenía que comparar los resultados del servidor con las imágenes que ya estaban en el disco.
Así que descargué cada URL disponible de los trabajos recientes y calculé su hash MD5. Después comparé esos hashes con los de las imágenes que ya estaban en la carpeta del proyecto.
Las coincidencias eran imágenes que ya tenía.
La que no coincidía con ninguna imagen local era la generación que faltaba.
Esa fue toda la recuperación. No reescribí el prompt. No volví a ejecutar la generación. No gasté otro crédito. Identifiqué el resultado remoto terminado descartando todos los resultados que ya tenían su archivo en el disco.
El coste de la recuperación fue de cero créditos.
El estado determina la solución
Un tiempo de espera agotado y un rechazo de moderación pueden aparecer en el mismo recuento de fallos, pero requieren respuestas distintas.
Un tiempo de espera agotado cuyo último estado sigue siendo in_progress significa que el cliente dejó de esperar. No demuestra que el servidor dejara de generar. El siguiente paso es revisar los trabajos recientes y cotejarlos con los archivos ya descargados.
Un rechazo de moderación con status: nsfw es distinto. Ese trabajo necesita otro intento con un prompt modificado. No hay una imagen terminada esperando a que la recuperes de la lista de trabajos recientes.
Meter ambos resultados en una misma categoría FAIL, sin distinguirlos, invita a actuar mal. Convierte un problema de descarga recuperable en una segunda generación de pago.
La pregunta útil no es «¿Ha fallado mi comando?», sino «¿A qué estado llegó el trabajo remoto?».
No son la misma pregunta.
Por qué no bastaba con comprobar los nombres de archivo
La recuperación dependía de comparar el contenido.
La lista de trabajos recientes contenía varios resultados y la carpeta local ya contenía varias imágenes. Consultar solo la lista demostraba que se habían terminado trabajos, pero no permitía identificar con certeza el que había quedado huérfano.
La comparación de MD5 me dio una respuesta mecánica. Cada imagen del servidor cuyo hash coincidía con un archivo local ya estaba localizada. El hash sin coincidencia señalaba la imagen que había terminado de generarse, pero nunca se había descargado durante el comando que agotó el tiempo de espera.
Esto importa sobre todo cuando se hacen varias generaciones muy seguidas. La prueba útil no es la etiqueta final del programa. Es la relación entre los resultados recientes del servidor y los archivos que realmente están en el disco.
El registro del servidor muestra lo que Higgsfield terminó. Los hashes muestran lo que ya tengo. La diferencia entre esos dos conjuntos es lo que hay que recuperar.
La regla que uso ahora
Un tiempo de espera agotado es un fallo de espera hasta que demuestre que fue un fallo de generación.
Cuando veo Timeout after ...; last status "in_progress", me detengo antes de volver a lanzar nada. Reviso los trabajos recientes, descargo las URL de sus resultados, comparo sus hashes MD5 con los de las imágenes del disco y recupero el archivo sin coincidencia.
Solo un rechazo confirmado, como status: nsfw, me hace volver al prompt.
Hoy, busca en tu programa de ejecución o en tus notas los puntos donde el tiempo de espera agotado y el rechazo de moderación siguen la misma ruta FAIL. Sepáralos antes de que la próxima imagen que agote la espera te haga pagar dos veces.
Cada solución de este artículo me costó primero un error. Mejor en mi película que en tu marca.
