@wilson @cadey iirc (from my Go-writing times) conceptually, context is supposed to be "an operation" -- something with a well-defined start/stop (it may spawn off sub-tasks, etc, but in the grand scheme of things it's a single overarching "thing" that you track from beginning to end).
Contrast that with a production service, which is a long-running listener that may spawn operations, but isn't a well-defined operation itself. It's a kinda different-but-related thing that wants an integration with contexts but isn't a context itself, and it often grows to want extra/different features (e.g. managing running requests with their own, standard timeouts, independent background loops which start & stop over the lifetime of the service, blocking until graceful shutdown, etc).
I guess a litmus test would be "could you conceivably put a timeout on it and not be unhappy".
Alternatively, would you conceptually model the thing as (in rust notation)
fn thing(in: Inputs) -> Outputs or
fn thing(in: Inputs) -> !. The former wants a context I think, the latter does not. 🤷♀️
On the internet, everyone knows you're a cat — and that's totally okay.