Lo que ve la persona usuaria no es el estado de todo el recorrido
En una función de inteligencia artificial (IA) con respuesta progresiva, cerrar la pestaña detiene la experiencia visible, pero no garantiza que el trabajo remoto haya terminado. El navegador puede abortar la lectura mientras PHP sigue esperando, un proxy conserva la conexión ascendente o el proveedor completa la generación y registra todos los tokens. Por eso una captura del navegador no basta para impugnar el consumo.
La pregunta útil no es «¿se cerró la pestaña?», sino «¿qué componente recibió la señal de cancelación y qué hizo con ella?». Para responderla, seleccione una solicitud concreta y reúna cuatro marcas temporales: navegador, endpoint de WordPress, transporte hacia el proveedor y registro final del proveedor. Convierta todas a UTC y conserve milisegundos si hay reintentos cercanos.
Reconstruya los cuatro relojes
Instrumente una prueba sin datos personales con un identificador común. A los 0 segundos, registre el envío; a los 8, provoque el cierre del cliente; anote cuándo PHP detecta la desconexión, cuándo termina la solicitud HTTP saliente y cuándo el proveedor declara completada o cancelada la operación. Añada el número de tokens facturados, no solo el texto que llegó a la pantalla.
No suponga que dos relojes idénticos prueban propagación. Un timeout local puede coincidir por casualidad con el fin remoto. Busque un estado explícito de cancelación, una conexión cerrada antes de la generación completa o una diferencia reproducible en tokens. Repita la prueba al menos cinco veces con la misma longitud máxima para separar una propiedad del sistema de una carrera ocasional.
| Reloj | Ejemplo | Dato que falta | Lectura operativa |
|---|---|---|---|
| Navegador | 00:08 abortado | Motivo y ID | La interfaz dejó de escuchar |
| WordPress | 00:09 detecta cierre | Hook de limpieza | La aplicación conoce la desconexión |
| Transporte | 00:41 respuesta final | Estado de socket | La llamada ascendente siguió abierta |
| Proveedor | 00:41 completado | Tokens facturados | El trabajo remoto terminó y se contabilizó |
Identifique el punto exacto donde se pierde la cancelación
Si WordPress nunca observa el cierre, revise el servidor web, el búfer y el proxy intermedio. Si lo observa pero no actúa sobre la solicitud saliente, la aplicación necesita una vía de cancelación o una política que no dependa de ella. Si se envía una cancelación y el proveedor aun así factura el trabajo ya realizado, documente esa semántica como límite externo en vez de prometer una detención instantánea.
También hay respuestas que conviene terminar aunque el navegador desaparezca: generar un archivo solicitado, actualizar un índice o completar una acción transaccional. Márquelas como tareas en segundo plano desde el diseño, con estado recuperable y presupuesto propio. Lo peligroso es que una interacción supuestamente efímera se convierta sin aviso en trabajo facturable que nadie puede consultar después.
Elija un control según la evidencia, no según la intuición
La propagación de cancelación es adecuada cuando todas las capas la admiten y el resultado parcial no tiene valor. Un límite máximo de salida protege incluso cuando la cancelación llega tarde. Tratar el proceso como tarea en segundo plano es coherente cuando el resultado se conserva para la persona usuaria. Estas medidas pueden combinarse, pero cada una responde a un fallo distinto y necesita una prueba separada.
Defina aceptación antes de programar: por ejemplo, en cinco cierres a los 8 segundos, ninguna generación supera el límite fijado; o bien todas quedan registradas como tareas recuperables con un único cargo. Incluya el caso en que la conexión cae sin evento de JavaScript. Una solución que depende exclusivamente de beforeunload no cubre una pérdida de red ni el cierre forzado del proceso.
La conclusión debe poder verse en la factura y en la experiencia
Tras el cambio, compare la cronología anterior y posterior, los tokens facturados y el comportamiento del cliente. Si el gasto baja pero la respuesta completa desaparece para conexiones brevemente inestables, el control puede ser demasiado agresivo. Si la experiencia mejora pero el proveedor sigue completando dos generaciones, el problema económico permanece.
Qué puede afirmar la capa de protección
Conserve la cronología junto con la configuración de protección y la fecha de revisión. Pro puede aportar límites y Smart Protection en las rutas cubiertas, pero no convierte una cancelación de navegador en una garantía sobre cualquier transporte personalizado. La evidencia de los cuatro relojes sigue siendo la base para decidir qué protección puede actuar y qué debe corregirse en la integración.
Use la Cronología de interrupción del streaming de «Cerrar la pestaña no siempre detiene el coste de una respuesta en streaming» en una primera instalación real. Descargue AI Cost Circuit Breaker gratis, empiece en Monitoring y active el bloqueo solo después de verificar señales y reversión.