requests transport advertises thread-safe conformance but shares a cookie-bearing requests.Session

[OmarAlJarrah]

Problem

The HttpClient Protocol states an explicit concurrency contract: "Implementations are expected to be safe for concurrent calls from multiple threads." The requests transport implements that Protocol by routing every execute() through a single shared requests.Session with cookie persistence left enabled. requests.Session has long-documented cookie-jar thread-safety races — the jar is mutated on every response — so a cookie-carrying workload driving this transport from multiple threads can corrupt the shared jar, which undercuts the very guarantee the Protocol advertises. Neither the module nor the class docstring notes the caveat.

Where

packages/dexpace-sdk-core/src/dexpace/sdk/core/client/http_client.py:23-24 (the contract):

Implementations are expected to be safe for concurrent calls from multiple
threads.

packages/dexpace-sdk-http-requests/src/dexpace/sdk/http/requests/client.py — every execute() uses the one shared session (self._session.request(...)), and the session is a plain requests.Session() with its default cookie jar.

Impact

Workload-dependent. A cookie-free workload is unaffected. A workload that carries cookies and drives this transport concurrently from multiple threads can hit requests' documented cookie-jar races, getting behaviour the Protocol says implementations should not exhibit — with no caveat in the transport's docs to warn the caller.

Suggested fix

Either disable cookie persistence on a self-owned session (so there is no shared mutable jar — appropriate since this toolkit follows redirects and manages state at the pipeline layer rather than relying on a transport cookie jar), or document explicitly on the class/module that the shared requests.Session is only concurrency-safe for cookie-free workloads and that callers needing concurrency with cookies must supply per-thread sessions.