No way to set a timeout on FeatureLayer.query()

[sgiacomel]

Describe the bug
When calling FeatureLayer.query() with a timeout parameter, the value is accepted without error but has no effect on the underlying HTTP request. Large layers can hang indefinitely as a result.

Root cause: FeatureLayer.query() accepts **kwargs and passes them to internal methods, but the timeout kwarg is never forwarded to the underlying requests.Session call.

To Reproduce
Steps to reproduce the behavior:

from arcgis.features import FeatureLayer
layer = FeatureLayer("https://example.com/arcgis/rest/services/.../FeatureServer/0")
# timeout is silently ignored — the request can hang indefinitely
features = layer.query(where="1=1", out_fields="*", return_geometry=True, timeout=10)

Expected behavior
The HTTP request should time out after 10 seconds.

Actual behavior
The request never times out regardless of the timeout value.

Platform (please complete the following information):

• Python API Version [2.4.1] (but I also saw that it is not fixed in 2.4.2 as well)`

Additional context
Add any other context about the problem here, attachments etc.

[nanaeaubry]

@sgiacomel There is no timeout parameter on the query method. Can you explain where you saw this documented that it takes this parameter?

[sgiacomel]

There is no timeout parameter on the query method. Can you explain where you saw this documented that it takes this parameter?

Yes, maybe I should rename this to something like: "No way to set a timeout on FeatureLayer.query()" rather than implying a timeout parameter exists but is ignored.

The query() method in arcgis does not document or accept a timeout parameter. What actually happens is that query() accepts **kwargs and passes them through, but they never reach the underlying HTTP call.

The bug is simply that there is no way to set a timeout on FeatureLayer.query() through the public API. The get() method in _connection.py (which handles the HTTP calls) never reads a timeout from kwargs — it just silently drops them.

Compare the signature methods with post_multipart (in the same file, a bit after). Both take path, params, and **kwargs. The key difference is that post_multipart() explicitly documents timeout as an optional parameter and pops it from kwargs (timeout = kwargs.pop("timeout", self._timeout)). The get() method has the same structure but simply never does that.

[sgiacomel]

Compare the signature methods with post_multipart (in the same file, a bit after). Both take path, params, and **kwargs. The key difference is that post_multipart() explicitly documents timeout as an optional parameter and pops it from kwargs (timeout = kwargs.pop("timeout", self._timeout)). The get() method has the same structure but simply never does that.

And the fact that the 2 signatures are very similar made me believe that this was an oversight in get() rather than an intentional design decision.

[nanaeaubry]

@sgiacomel You can set a timeout on the GIS object and this will be used for all method subsequently called with that GIS instance.
In your code above, the GIS used for the FeatureLayer class instantiation is whatever active gis can be found in your environment.

timeout is accepted as a keyword argument in the GIS instance and the default is 600 seconds.

[sgiacomel]

You can set a timeout on the GIS object and this will be used for all method subsequently called with that GIS instance. In your code above, the GIS used for the FeatureLayer class instantiation is whatever active gis can be found in your environment.

timeout is accepted as a keyword argument in the GIS instance and the default is 600 seconds.

Thanks for the suggestion. You're of course right that GIS(timeout=...) sets self._timeout on the connection object.
However, looking at the source of _connection.py, self._timeout is only read in post_multipart() (line 1103) and is never passed to the underlying request in the get() method. It seems to me that since FeatureLayer.query() goes through _query.py which calls _con._session.get(), the configured timeout is silently ignored for GET-based queries.