Summary

  • The ten-second HTTP setting in the reviewed RIPE Atlas Tools sources is passed to Google geocoding, but not to the Atlas measurement-creation request through Cousteau.
  • A local capture test with settings 3, 10 and 30 confirms the parameter boundary. It made no network requests, created no measurements and establishes neither a live outage nor the behaviour of every installation.

Follow the number

In RIPE Atlas Tools, the ten-second http-timeout setting reaches Google's geocoder. It stops short of the code that asks Atlas to create a measurement. The name of the setting sounds broad; its concrete consumers are what determine its reach.

The official release history dates version 3.4.0 to 3 June 2026 and lists a configurable HTTP timeout with a default of ten seconds. This is a September examination of that published work, not news of a September release. The settings source defines the value. In the probe-search command, a geographic lookup passes it to Requests and handles timeout errors. That part of the control is visible and real.

Measurement creation follows another path. The tools construct an AtlasCreateRequest with an API server, authorisation key, user agent, measurement definitions, probe sources and one-off status. They do not pass the HTTP timeout value. In the reviewed Cousteau 2.3.0 source, that class inherits the common AtlasRequest. Its HTTP argument dictionary contains parameters, headers, TLS verification and proxies. A POST adds the JSON body. The final call hands that dictionary to Requests without a timeout parameter.

The distinction is narrower, and more useful, than saying “Atlas has no timeout”. A third-party geographic lookup has a configured timeout. A particular Atlas request path does not receive it. Other clients, custom wrappers, later dependency versions and external process controls have not been audited here.

Three values, no live campaign

For this investigation, the genuine creation and geocoding methods were extracted from pinned source, together with the SDK's request and creation classes. They were executed locally with synthetic measurement definitions, source builders and captured transport functions. The transport fixtures returned local test data; they were not Atlas responses.

Changing the HTTP setting to 3, 10 and 30 sent precisely those values to the geocoding call. In all three cases, the captured Atlas POST argument dictionary lacked a timeout. No network function was available to the extracted code. There was no API key, actual measurement, remote job or credit expenditure.

This tests parameter propagation in those methods and classes. It is not a full command-line run, an installed-package integration test, a server-response experiment or a latency measurement. The missing argument is evidence about the client path. It is not evidence that an operator waited thirty seconds, that an Atlas server stalled or that a campaign failed.

The code also answers a possible alternative explanation: the value is not silently inherited merely because the CLI and SDK belong to the same institution's tooling. Configuration has to reach the layer that constructs the HTTP call. In the reviewed path, it does not.

A timeout is not a stopwatch

Requests' own documentation makes two distinctions worth retaining. Without an explicit timeout, its calls have no specified Requests timeout. With one, the number is not a deadline for downloading the entire response. A socket-level waiting rule is different from a total task budget.

It therefore would be wrong to promise that even the geocoding operation always finishes in exactly ten seconds. It would also be wrong to claim that an Atlas call must wait forever: operating systems, connections, proxies or an outer supervisor can still end a wait. This source inspection did not inventory those controls.

Nor should HTTP waiting time be confused with a probe's packet timeout or a stream consumer's observation limit. The former concerns communication with an API; the latter concern measurement or collection behaviour. A delayed creation reply does not itself reveal slow probes or an impaired network path.

The operating consequence

The practical problem is an uncertain boundary, not a demonstrated outage. An operator reading a global-looking HTTP setting needs to know which operations it governs. Otherwise a workflow may classify a locally abandoned request as a rejected remote job even though that conclusion does not follow.

Consider a creation request whose reply is lost after the server has accepted it. That is a scenario, not something this test observed. Before deciding to submit again, the operator needs an authorised record of the remote result, or must preserve the state as unknown. A local deadline is not proof of server-side rejection, and cancellation of a local process is not automatically cancellation of a remote task.

A useful operating description would name the geocoding path, the Atlas SDK path and the outer task control separately. It would give each a responsible layer and explain how an unknown result is reconciled. It need not force every operation into the same ten-second rule.

Sources