Resumen

  • El ajuste HTTP de diez segundos sí se aplica al geocodificador en las fuentes examinadas de RIPE Atlas Tools, pero no se transmite a la creación de mediciones Atlas mediante Cousteau.
  • Una captura local con valores 3, 10 y 30 verifica ese recorrido sin conexiones, claves, mediciones ni gasto de créditos. No demuestra una avería real ni representa todas las instalaciones.

Dos solicitudes, distinto control

La consulta de una ubicación y la petición para crear una medición no recorren el mismo software. Esa diferencia explica por qué el ajuste http-timeout de RIPE Atlas Tools llega a Google, pero no a la solicitud Atlas que hemos examinado.

La versión 3.4.0 figura en el historial oficial con fecha de 3 de junio de 2026. Entre sus cambios aparece un tiempo de espera HTTP configurable, fijado por defecto en diez segundos. Esta investigación de septiembre revisa aquella publicación; no anuncia una versión estrenada ahora.

En la búsqueda de sondas, el código que obtiene coordenadas de Google entrega expresamente ese ajuste a Requests y contempla errores de tiempo de espera. Es un control con un consumidor identificable. No hay que descalificarlo porque otra operación siga un camino diferente.

La creación de una medición pasa al SDK. La herramienta entrega a AtlasCreateRequest el servidor de la API, la clave de autorización, la identificación del cliente, las definiciones, las fuentes de sondas y el indicador de ejecución única. No entrega el valor HTTP.

El código revisado de Cousteau 2.3.0 muestra cómo continúa el recorrido. AtlasCreateRequest hereda de AtlasRequest; los argumentos HTTP incluyen parámetros, cabeceras, verificación TLS y proxies. Para un POST se añade el cuerpo JSON. El último paso entrega ese conjunto a Requests sin un parámetro de tiempo de espera.

No es una afirmación sobre todos los clientes de Atlas. Tampoco demuestra que todas las llamadas del programa estén desprotegidas: el geocodificador es precisamente un caso contrario. La evidencia corresponde a las fuentes y al trayecto examinados.

Una comprobación que no envía mediciones

Para seguir el valor aislamos las funciones reales de creación y geocodificación, junto con las clases de solicitud y creación del SDK, mediante su estructura sintáctica. Se ejecutaron localmente con definiciones y fuentes sintéticas. Las funciones de transporte capturaban los argumentos; sus respuestas eran datos de prueba, no contestaciones del servidor Atlas.

Cuando el ajuste valía 3, 10 o 30, la llamada al geocodificador recibía 3, 10 o 30. Ninguno de los tres POST capturados para Atlas incorporaba un parámetro de espera. El código aislado no tenía funciones de conexión disponibles. No se usaron claves, no se crearon trabajos y no se consumieron créditos.

El resultado verifica la transmisión de un parámetro en esos métodos. No equivale a ejecutar toda la aplicación instalada, probar todas sus dependencias en integración o medir el servicio en producción. No sabemos por esta prueba cuánto esperó ningún usuario, si hubo un atasco de servidor o qué controles externos tenían las instalaciones reales.

Que dos componentes formen parte del mismo entorno institucional no convierte la configuración en una propiedad heredada. El número debe llegar al código que construye la llamada. Aquí puede señalarse el lugar concreto donde deja de viajar.

No son diez segundos de principio a fin

Requests distingue entre proporcionar un tiempo de espera y no proporcionarlo. Sin parámetro explícito, sus llamadas no tienen un tiempo de espera especificado. Pero incluso con él, el valor no limita la duración completa de la descarga de una respuesta.

Por eso sería incorrecto prometer que la consulta geográfica termina siempre diez segundos después de iniciar el comando. También sería incorrecto traducir la ausencia del parámetro en una espera necesariamente eterna. El sistema operativo, la conexión, un proxy o un supervisor del proceso pueden interrumpirla. No se investigaron aquí esas reglas.

Hay otra distinción que afecta a la lectura de los resultados. La espera HTTP ante una API no es el plazo de una sonda para recibir paquetes ni el límite de observación de un consumidor de resultados. Una respuesta de creación tardía no mide la latencia de las sondas.

El resultado desconocido también cuenta

Un escenario ilustra la consecuencia. Si el servidor acepta crear un trabajo y se pierde la respuesta, cerrar el cliente no acredita que la operación haya sido rechazada. Esta posibilidad no se produjo en nuestra prueba, que nunca contactó con Atlas.

Antes de decidir si repite la solicitud, el operador necesita cotejar un registro remoto al que tenga acceso autorizado, o conservar el resultado como desconocido. La interrupción local y la cancelación de un trabajo remoto son decisiones distintas. El parámetro de espera, por sí solo, no resuelve esa relación.

Una descripción operativa útil identificaría por separado la consulta a Google, la llamada Atlas del SDK y el límite global impuesto por la automatización. No necesita imponer a las tres el mismo número. Necesita decir qué controla cada una y quién debe aclarar el estado cuando termina la espera.

Fuentes