how to do client API calls with a context that has been passed from an upstream service, etc.?

[thediveo]

Background: I'm trying to integrate Podman support into my whalewatcher container workload monitoring Go module. whalewatcher is used in other projects, such as the downstream lxkns container-aware Linux-kernel namespace discovery service.

The typical Go context pattern seems to me to be that contexts gets passed down, for instance, from HTTP handlers in form of a request's context.

From looking at the Podman API documentation, things unfortunately look to be topsyturvy: when creating a Podman connection, not the connection itself gets returned, but instead a new context that has the connection attached to it as a value. Now I'm scratching my head: when an HTTP service handler needs to make an API call, that call must be cancelled when the request's context is cancelled. However, I cannot use the request context, as it lacks the attached connection value. The context returned by NewConnection seems pretty useless to me, as it won't ever by cancelled when the important request context gets cancelled.

When I'm creating the connection I don't know yet which services will use it with what contexts. That's the way so many other Go APIs work, such as the k8s control plane APIs.

What am I missing?

Or do I have to extract the connection value and attach it to the request context and then use this new context for my Podman API calls?

[thediveo]

Looks like I need to work around this myself. For the sake of others that might some day trip into this API design, I've created a tiny Go module named wye as in "Y": it "mixes" a typically shorter-lived (service) context into a long-living context, such as podman's "connection" context. It basically acts as a "Y" joint for Go contexts with respect to deadlines/timeouts and cancellations; the opposite of Go's common "⅄" context-deriving pattern.