ClientwrightProvider takes no component=, so several upstreams in one container are unreachable

[AlexeyShalaev]

We went to adopt clientwright.contrib.dishka and could not register it, for the reason its
own docstring names:

For several upstreams, instantiate one provider per upstream in separate containers, or
subclass and add typed aliases.

Separate containers is not available to us — the upstreams are dependencies of the same
use cases — and ClientwrightProvider takes no component=, so two of them in one container
both provide ClientRuntime and ClientHandle[Any] on the same keys.

What that looks like here

social-idp-bridge builds five clients from one container — Google OAuth, GitHub login,
GitHub API, LinkedIn login, LinkedIn API — each with its own ClientConfig, two of them
handed to the same object:

@provide
async def get_github_oauth_provider(self, settings: Settings, ...) -> AsyncIterator[GitHubOAuthProvider]:
    async with (
        self.rest_client(settings.oauth.github.client,     "github-oauth") as login_client,
        self.rest_client(settings.oauth.github.api_client, "github-api")   as api_client,
    ):
        yield GitHubOAuthProvider(login_client=login_client, api_client=api_client, ...)

auth-orchestrator has two (credential-service, social-idp-bridge), session-token-service
one. Eight clients across three services, none of which can be one-provider-per-container.

The asymmetry worth noting

grpc_client_kit.dishka — the sibling module in the same family — solved exactly this:

container = make_async_container(
    *grpc_client_providers(settings.users_grpc,  component="users"),
    *grpc_client_providers(settings.orders_grpc, component="orders"),
)
users = await container.get(GrpcClientFactory, component="users")

Every provider there takes component=, and the docs explain the trade-off. The same
component= on ClientwrightProvider would make one-container-many-upstreams a supported
shape rather than a documented limitation, with no change to the single-upstream case.

Two smaller things in the way

Typed injection. The provider hands out ClientHandle[Any]; consumers want the native
client. The docstring suggests subclassing to add a typed alias, which is fine once
component= exists — but a shipped httpx.AsyncClient alias (or a documented two-line
recipe) would save every consumer writing the same subclass.

The circuit-state gauge. The module already notes it:

the http_client_circuit_state gauge is wired when the ADAPTER builds the runtime; a
runtime built here (to be shared) has no telemetry listener, so state-change events are not
exported as a gauge.

That is a metric we currently export, so adopting the provider as it stands would be a
regression on our dashboards. Not a blocker on its own, but it lands in the same decision.

Where we are

We keep a 73-line RestClientProvider whose whole job is "several clientwright clients from
one provider, each closed when its scope ends". It is a base class services subclass with one
generator @provide per upstream. We would rather delete it.

Worth saying that writing it the naive way is a trap you already flagged: ours parked
aclose on an AsyncExitStack nobody closed and leaked a client per request, at
Scope.REQUEST — the legacy-kit bug your docstring calls out, arrived at independently. We
have just fixed it the way you prescribe, close travelling with the provide. Whatever shape
the multi-upstream answer takes, that property is the one we care about keeping.

[AlexeyShalaev]

Agreed on the diagnosis. Both provides key on ClientRuntime and ClientHandle[Any] in dishka's default component, and the class has no way to be told which upstream it is, so a second instance is a collision by construction. The three things you list all fall out of that one gap, so I'm taking all three in one feat:.

ClientwrightProvider(adapter, config, deps=None, *, component=None) — the keyword goes straight to Provider.__init__, same as every provider in grpc_client_kit.dishka. Dishka resolves the handle's ClientRuntime dependency inside the provider's own component, so each upstream gets its own runtime, its own client and its own close, nothing shared between them. I checked this against dishka 1.10.1 before designing rather than reading it off the docs: two instances with different components in one container resolve to distinct handles and distinct runtimes, the runtime each handle carries is the one its component hands out, a request scope opening and closing leaves the client open, and closing the container closes both. The default component is untouched, so the one-upstream case changes nothing. No bundle helper: grpc_client_providers exists because that kit has three providers per upstream; here the provider is the bundle, and ClientwrightProvider("httpx", cfg, component="github-api") is already the one-liner.

Typed injection ships as client_type=: when given, the provider also provides the native client under that type, in the same component, out of the same handle. Your constructor then reads login: Annotated[httpx.AsyncClient, FromComponent("github-oauth")], api: Annotated[httpx.AsyncClient, FromComponent("github-api")] and the RestClientProvider goes. I rejected a built-in httpx.AsyncClient provide (the module serves five adapters and cannot name an SDK type) and the subclass recipe the docstring suggests today (it leaves every service writing the class you want to delete).

The gauge is fixable in the provider. Every adapter does runtime = deps.runtime or ClientRuntime.for_config(config, circuit_listener=telemetry.circuit_state_changed) — the listener is attached only on the branch where the adapter builds the runtime, and the provider always hands one in, so it was never attached through DI. The runtime provide will build it the way the adapter does: a ClientTelemetry over deps.metrics, gated by config.observability.metrics, wired as the circuit listener. A runtime you pass in yourself via deps.runtime (the sharing-across-rebuilds recipe) is handed back as-is, listener included, exactly as with build(); the "known limitation" shrinks to that already-documented rule. Test: a breaker tripped on a provider-built runtime moves http_client_circuit_state to 2 on a real Prometheus registry.

Close travelling with the @provide stays exactly as it is, and gets pinned: a test that enters and leaves a request scope and asserts the client is still open, then closes the container and asserts it is closed. The multi-component test asserts each client is closed on container close.

Docs: the DI guide (components, typed injection, the gauge paragraph), the contrib reference, and the agents page (the provider row, the telemetry table row, rule 2), plus the module docstring. One thing to confirm on your side: with components, every injection site names the upstream — FromComponent("github-api") or container.get(..., component="github-api") — there is no way around that in dishka, and it is the same trade-off the grpc-client-kit page describes. If that is fine for the eight clients, I'll go ahead.

[AlexeyShalaev]

Shipped in #36, on top of 0.3.0.

ClientwrightProvider("httpx", config, component="github-api", client_type=httpx.AsyncClient), one per upstream, in the container's argument list. The runtime and the handle land in that component and dishka resolves the handle's runtime inside it, so each upstream is its own breaker, budget and client, and each client is closed in the same generator finally as before. A single upstream in the default component changes nothing. client_type= adds a provide of the native client under that type, out of the same handle, so the constructor from your snippet becomes

class GitHubOAuthProvider:
    def __init__(
        self,
        login_client: Annotated[httpx.AsyncClient, FromComponent("github-oauth")],
        api_client: Annotated[httpx.AsyncClient, FromComponent("github-api")],
    ) -> None: ...

and the generator provides that built the clients, and the RestClientProvider under them, go. That exact class is a unit test now, resolved from two components in one container and closed with it.

The gauge was fixable in the provider. Every adapter attaches the http_client_circuit_state listener only to the runtime it builds itself, and the provider always handed one in, so the listener never existed through DI. The runtime provide now builds it the way an adapter does, so with AdapterDeps(metrics=PrometheusClientMetrics()) a provider-built runtime moves the gauge like build() does; the test trips a breaker and reads 2.0 off a real registry. The one runtime that still carries no listener is one you build yourself and pass through AdapterDeps(runtime=...), which is handed back as it came, same as with build().

Close travelling with the @provide is pinned: a test opens and closes a request scope and asserts the client is still open, then closes the container and asserts it is closed; the two-component test asserts both clients closed.

On your side, the one thing to change besides deleting the provider: name the component at every injection site, FromComponent("github-api") or container.get(..., component="github-api"). The default-component key does not resolve a provider that was given a component, by dishka's design. It is a feat:, so it goes out as a minor once merged.