Disabling context_propagation doesn't disable gRPC traceparent header injection (golang)

[miloszivkovic]

Component

OBI (eBPF instrumentation)

What happened?

Hello folks,

Noticed that regardless of context_propagation flag my go app injects traceparent header in case of grpc protocol.

Notes:

• I've been using ebpf-instrument:main and I'm aware that support for http2/grpc was added just recently.
• I'm not sure if this happens with non-go apps.
• I'm not sure if this happens with non-grpc traffic.

Setup:

• amd64 architecture
• kernel 6.12.68+
• go 1.25
• grpc v1.81.1
• image otel/ebpf-instrument:main

What did you expect to happen?

Expected that traceparent header is not injected when the flag is disabled.

Steps to reproduce

1. Deploy OBI with context propagation disabled

ebpf:
      context_propagation: disabled
      track_request_headers: false

2. Then deploy two simple golang apps (client and server), where server logs request metadata, something like this:

func (s *server) Ping(ctx context.Context, req *pb.PingRequest) (*pb.PingResponse, error) {
	if md, ok := metadata.FromIncomingContext(ctx); ok {
		log.Printf("ALL METADATA: %v", md)
		if tp := md.Get("traceparent"); len(tp) > 0 {
			fmt.Printf(">>> TRACEPARENT RECEIVED: %s\n", tp[0])
		}
	} else {
		log.Printf("No metadata in request")
	}
	return &pb.PingResponse{Data: []byte("pong")}, nil
}

server app logs:

2026/06/09 07:04:33 ALL METADATA: map[:authority:[grpc-server:9090] content-type:[application/grpc] traceparent:[00-b39d8d08493afd5eb181267c6c45d8e9-79434a69bf84b013-01] user-agent:[grpc-go/1.81.1]]

OBI configuration

Relevant logs

Additional context

No response

Version

No response

Kernel version

No response

OS / Distribution

No response

Deployment

Kubernetes

[grcevski]

Yes you are correct. We need to start taking into account that option for the Go side. The Go context propagation has two implementations, one that's common with the context_propagation flag and a Go specific one that works for the standard Go HTTP and gRPC libraries. This second implementation doesn't take the context_propagation option into account.

[mohd-ibadullah]

Hi @grcevski,

I'd like to work on this issue.

From your explanation, it sounds like the Go-specific HTTP/gRPC context propagation path is not currently honoring the context_propagation configuration, unlike the common implementation.

I'll investigate the Go propagation flow, update it to respect the configured option, and add regression tests to verify that trace headers are not injected when propagation is disabled.

Thanks!