Should we be running `object_store` tokio tasks on the runtime provided by `pyo3-async-runtimes`?

[kylebarron]

object_store has a SpawnedReqwestConnector, which allows for all requests made by object_store to be done on the provided runtime. Should we be passing that in?

        let connector = SpawnedReqwestConnector::new(get_runtime().handle().clone());
        builder = builder.with_http_connector(connector);

Right now, is there a new tokio runtime created for each client..?

[kylebarron]

Written by claude

Some context after digging through the code (written by Claude):

Is a new runtime created per client?

No. There's a single, process-global, lazily-initialized multi-threaded tokio runtime owned by pyo3-async-runtimes (get_runtime() → static TOKIO_RUNTIME: OnceLock<...> with Builder::new_multi_thread()). Every sync/async op in obstore (get, put, list, delete, head, copy, rename, buffered, signer) drives its futures on that one runtime via get_runtime(). It lives for the whole process and is shared across all clients — there is no per-client runtime.

How HTTP is wired up today

Stores are built synchronously in Python __init__/from_url, i.e. outside any tokio runtime. None of our builders call with_http_connector, so object_store falls back to the default ReqwestConnector, which builds a plain reqwest::Client at build() time. That client only binds to a runtime when the first request is dispatched — which always happens inside get_runtime(). Since that runtime is global and never dropped, the default path works fine in normal usage.

What SpawnedReqwestConnector would change

It wraps the client in a SpawnService that runtime.spawn(...)s every request onto an explicit Handle, bridging results back over oneshot/mpsc channels. Its documented purpose is to segregate I/O onto a known runtime and guard against the "client built/used on a runtime that later goes away or differs" failure mode (the reqwest "IO driver shut down" / "dispatch task gone" panics).

Takeaway

• In normal obstore usage this is largely belt-and-suspenders: there's already exactly one global runtime, so the default connector binds reqwest to that same runtime. Passing SpawnedReqwestConnector::new(get_runtime().handle().clone()) mostly just makes that binding explicit and guaranteed.
• It would matter if obstore is ever driven from a foreign tokio runtime (another Rust extension's runtime), or if we ever stop routing everything through get_runtime(). In those cases the default connector could pin connections to the wrong/short-lived runtime and panic; the spawn connector is the robust fix.
• Costs: an extra task spawn + channel hop per request, plus an unbounded mpsc for streaming bodies (intentional, to avoid cross-runtime backpressure deadlock).
• Scope: if we adopt it, it needs threading into all builders (aws, gcp, azure, http) plus the credential/signer clients, not just S3.