pubsub: panic when using tracing due to nil Span interface

[magnusewe]

Client

PubSub v2.4.0

Environment

Go v1.25.8

Code and Dependencies

// Creating a client with otel tracing enabled:
client, err := pubsub.NewClientWithConfig(
	ctx,
	projectID,
	&pubsub.ClientConfig{
		EnableOpenTelemetryTracing: true,
	},
)

// Pulling messages...

Expected behavior

No panics in the pubsub library.

Actual behavior

Nil interface panic when the v2 subscriber calls ccSpan.End().
This started happening after the client had been running for a while.

panic: runtime error: invalid memory address or nil pointer dereference                                                                               
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xdfd902]                                                                                                                                                                                       
                                                                                                                                                                                                                                                              
goroutine 408 [running]:                                                                                                                                                                                                                                      
cloud.google.com/go/pubsub/v2.(*Subscriber).Receive.func2()                                                                                                                                                                                                   
    cloud.google.com/go/pubsub/v2@v2.4.0/subscriber.go:397 +0x682                                                                                                                                                                                             
golang.org/x/sync/errgroup.(*Group).Go.func1()                                                                                                                                                                                                                
    golang.org/x/sync@v0.19.0/errgroup/errgroup.go:93 +0x50                                                                                                                                                                                                   
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 312                                                                                                                                                                                            
    golang.org/x/sync@v0.19.0/errgroup/errgroup.go:78 +0x95

This happens because ccSpan is never assigned when iter.activeSpans.Load(ackh.ackID) returns false.

google-cloud-go/pubsub/v2/subscriber.go

Lines 406 to 428 in 2507934

	var ccSpan trace.Span
	if iter.enableTracing {
	c, ok := iter.activeSpans.Load(ackh.ackID)
	if ok {
	sc := c.(trace.Span)
	otelCtx = trace.ContextWithSpanContext(otelCtx, sc.SpanContext())
	// Don't override otelCtx here since the parent of subsequent spans
	// should be the subscribe span still.
	_, ccSpan = startSpan(otelCtx, ccSpanName, "")
	}
	}
	// Use the original user defined ctx for this operation so the acquire operation can be cancelled.
	if err := fc.acquire(ctx, len(msg.Data)); err != nil {
	// TODO(jba): test that these "orphaned" messages are nacked immediately when ctx is done.
	for _, m := range msgs[i:] {
	m.Nack()
	}
	// Return nil if the context is done, not err.
	return nil
	}
	if iter.enableTracing {
	ccSpan.End()
	}

[hongalex]

Thanks for filing an issue and the detailed report.

I suspect the cause of iter.activeSpans.Load returning false is that the subscriber is backed up and hits its flow control concurrency limits. When the message expires, the span is ended and its entry in activeSpans is deleted in iter.handleKeepAlives

Since the intended behavior is to continue passing the message to the callback (even if the local client thinks it has expired), we can fix this by introducing a simple ccSpan != nil guard before terminating the span.