Cancelé la tanda de imágenes, pero seguía gastando créditos
Cancelar una tanda en Windows dejé activos sus procesos hijos. Seguían generando imágenes y gastando créditos aunque la tarea figuraba detenida.
Seguían apareciendo nuevos PNG después de detener la tanda en segundo plano.
El saldo de créditos también seguía bajando.
El comando de parada había indicado que la tarea estaba cancelada, así que la tanda parecía detenida desde la interfaz con la que la había lanzado. En Windows, ese resultado no significaba que se hubiera detenido todo el árbol de procesos.
Dos procesos bash.exe seguían ejecutando la tanda de generación. Uno pertenecía a una ejecución de GPT que yo había «detenido» media hora antes. El otro pertenecía a una ejecución de nano. Por debajo de ellos, la cadena de generación seguía activa:
sh.exe → node.exe → hf.exe
El proceso contenedor se había detenido. Sus hijos, no.
Cancelar el proceso padre no bastaba
La tanda se ejecutaba en segundo plano mediante Git Bash en Windows. Dentro había un bucle que seguía leyendo el trabajo pendiente y lanzando comandos de generación de Higgsfield.
Detener la tarea en segundo plano terminaba el proceso contenedor asociado a ella. La orden de terminación no se propagaba por el árbol de procesos hijos. El bash.exe hijo seguía activo como proceso huérfano y su bucle while read continuaba recorriendo la tanda.
Por eso la interfaz y la carpeta de salida contaban historias distintas.
La interfaz decía que la tarea se había detenido. La carpeta seguía recibiendo imágenes porque el proceso real de generación todavía tenía descendientes activos. Higgsfield seguía recibiendo peticiones, así que se seguían gastando créditos.
El nombre de un proceso no bastaba para identificar el árbol correcto. En Windows puede haber varios procesos de shell, Node o línea de comandos abiertos a la vez. Terminar todos los procesos con un nombre de ejecutable común habría sido impreciso.
El identificador útil era la línea de comandos.
Revisé los procesos activos por su línea de comandos
La comprobación verificada utilizaba Win32_Process:
Get-CimInstance Win32_Process |
Where-Object { $_.CommandLine -match 'generate-faces|higgsfield' }
Así aparecían los procesos cuyas líneas de comandos contenían los términos de la tanda o de la generación de Higgsfield.
Esa comprobación encontró los dos procesos bash.exe que seguían activos y la cadena de procesos hijos. No dependía de que la interfaz de tareas en segundo plano los recordara. Consultaba a Windows qué seguía ejecutándose.
Revisé las coincidencias antes de detener nada. La línea de comandos vinculaba cada PID con el trabajo de generación de pago. Eso es más seguro y útil que buscar bash.exe de forma aislada, porque bash.exe solo me dice qué ejecutable está funcionando. No me dice qué está haciendo.
Después de identificar los PID correctos, utilicé Stop-Process -Force sobre cada proceso del árbol de generación.
Lo importante no era la opción de terminación forzada por sí sola. Era la selección previa de los PID. Había vinculado cada proceso con la tanda a través de su línea de comandos.
La segunda comprobación importaba tanto como la parada
No tomé el comando de parada como prueba de que el trabajo había terminado. Esa suposición ya había fallado una vez.
Después de detener los PID identificados, volví a revisar la lista de procesos con ps aux | grep, buscando los mismos términos de la tanda y de Higgsfield. Solo di la tanda por detenida cuando no quedaba ninguno de los procesos implicados.
Esa comprobación final cubre la distancia entre dar una orden de terminación y confirmar su efecto.
En una tanda local corriente, una shell huérfana puede ser una molestia. En una tanda de generación de pago, es un gasto activo. Cada iteración puede crear otra tarea aunque yo crea que he cancelado la ejecución.
La carpeta de salida ofrece otra advertencia. Si siguen apareciendo archivos, la tanda no está detenida, diga lo que diga el proceso contenedor. El saldo de créditos ofrece la misma advertencia desde el lado de la facturación.
Pero ninguna de esas señales debería ser el control principal. Para cuando aparece otra imagen o cambia el saldo, puede que ya se haya enviado otra petición. La comprobación directa está en el árbol de procesos.
Cambié lo que registra la tanda
Los scripts de tandas de pago deben registrar su PID.
Eso me da un punto de partida preciso cuando necesito detener una ejecución. Puedo identificar el proceso registrado, revisar sus descendientes y confirmar qué líneas de comandos pertenecen a la tanda.
El PID no elimina la necesidad de verificar los procesos hijos en Windows. Agiliza la comprobación y reduce la ambigüedad cuando hay varias shells activas.
El procedimiento completo de parada forma ahora parte de la ejecución de la tanda, en lugar de ser una limpieza de emergencia posterior:
Iniciar la tanda y registrar su PID. Al cancelar, detener la tarea correspondiente. Consultar Win32_Process en busca de líneas de comandos coincidentes. Detener cada proceso confirmado del árbol de generación. Volver a comprobar hasta que no quede ningún proceso implicado.
Solo entonces está detenida la tanda.
La regla que aplico ahora
Un mensaje de cancelación correcta no demuestra que una tanda de pago en Windows haya terminado.
La prueba es que la búsqueda de procesos de esa tanda y de su comando de generación no devuelva resultados. Si bash.exe, sh.exe, node.exe o hf.exe siguen asociados a la línea de comandos coincidente, el trabajo puede continuar.
Si ejecutas tandas de IA de pago en Windows, añade hoy el registro del PID. La próxima vez que canceles una, consulta Win32_Process por línea de comandos y verifica que haya desaparecido todo el árbol antes de dar la parada por confirmada.
Cada solución de este artículo empezó con un error que pagué yo. Mejor en mi película que en tu marca.
