Pass a copy of main goroutine context to subroutine context

I have a golang API endpoint with a context associated with it.

The endpoint needs to do some heavy lifting behind the scenes, so I create a new sub routine within the main endpoint and return the response then there itself.

In order to deal with context cancellation, I am creating a background context and pass this as the new context to the subroutine.

The problem is by doing this, yes, I can execute the background subroutine, but the values within the main context such as request id, span id etc. (most of keys are unknown to me), which are being used for tracing will be lost.

How do I pass a parent context to the subroutine without cancelling the the execution even after the response is sent to the client.

EDIT

I am not passing any values into the context.
But initially we are passing request-id, span-id etc. which are needed for tracing.
These informations are in the context.
This is an internal library, and context is the place were we are keeping this.

I know this is an anti-pattern for using context to pass values, and no values is passed, except the request-id and other values that important to the library not to the business logic

When you cancel a parent context, all contexts derived from it will also cancel. So you are correct in creating a new context for goroutines spawned from a request handler.

When you create a new context, you should copy all the values you are interested in from the original context to the new context. However, you said you don't know all the keys. So you can still keep a reference to the parent context so that you can query it for values. Something like this:

type nestedContext struct {
   context.Context
   parent context.Context
}

func (n nestedContext)  Value(key any) any {
   return n.parent.Value(key)
}

...
newContext := nestedContext{
   Context:context.Background(),
   parent: parentContext,
}

This will create a new context from the context.Background() that will lookup values from the canceled parent context.

Pass newContext as the context to the goroutines created from the handler.

> Package context defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes. context

> For incoming server requests, the context is canceled when the client's connection closes, the request is canceled (with HTTP/2), or when the ServeHTTP method returns. net/http

Is it an anti-pattern to send values through a context, that lives longer than the request itself?
I do believe it is, but some could argue about this. Waiting for comments...

I created a cantCancelMe struct that implements the context interface and can never be cancelled. Pretty unorthodox and scary but it was fun to code and that's exactly what you want to achieve. Make sure you understand the side effects and leave some clues in the comments if there's other people working on the same codebase.

package main

import (
	"context"
	"fmt"
	"time"
)

func main() {
	ctx, connClose := context.WithCancel(context.Background())
	handler(ctx)
	connClose() // cancel here to simulate a conn close

	<-time.After(time.Hour)
}

// Define your own type of context, that can't be cancelled(literally:)
type cantCancelMe struct {
	// Receive anyting that implements Context interface(including the context
	// which holds your values and gets cancelled early by the handler)
	context.Context
}

/*
Then override everything that could cancel it, while leaving Values()untouched:
*/

// Deadline returns ok==false when no deadline is set.
func (cantCancelMe) Deadline() (deadline time.Time, ok bool) {
	return time.Time{}, false
}

// Done may return nil if this context can never be canceled.
func (cantCancelMe) Done() <-chan struct{} {
	return nil
}

// If Done is not yet closed, Err returns nil
func (cantCancelMe) Err() error {
	return nil
}

/*
A simplified handler that injects a regular context into the first routine
and a "cantCancelMe" context into the second routine:
- the first routine will receive the cancel signal immediately
- the second routine will never receive a cancel signal (sounds scarry)
*/
func handler(ctx context.Context) {
	regularCtx := context.WithValue(ctx, "reqID", "regular")
	notCancellableCtx := cantCancelMe{
		context.WithValue(ctx, "reqID", "nerver-cancel-ctx"),
	}
	go longRunning(regularCtx)
	go longRunning(notCancellableCtx)
}

func longRunning(ctx context.Context) {
	for {
		select {
		case <-ctx.Done():
			fmt.Printf(`handler ctx was cancelled, while I was still working on 
			reqID=%s\n`, ctx.Value("reqID"))
			return
		case <-time.After(time.Second):
			fmt.Printf("heavy duty for reqID=%s\n", ctx.Value("reqID"))
		}
	}
}

$ go run main.go
handler ctx was cancelled, while I was still working on reqID=regular
heavy duty for reqID=nerver-cancel-ctx
heavy duty for reqID=nerver-cancel-ctx
[...]