Thanks for reporting this issue. I'd like to clarify how tracing typically works in this context:

The router.Route() usually serves as the entry point when messages are received. Here's a common pattern:

func (svc *Service) onPublishReceived(p paho.PublishReceived) (bool, error) {
  ctx, span := tracer.Start(context.Background(), "message_route") // root span
  defer span.End()
  m.router.Route(ctx, p.Packet.Packet())
  return true, nil
}

func (svc *Service) defaultHandler(ctx context.Context, p *paho.Publish) {
  ctx, span := tracer.Start(ctx, "default_handler")
  defer span.End()

  doWork(ctx) // continue propagating the span
}

The flow works as follows:

A root span is created at message reception
The context is passed through router.Route()
Handlers can create child spans
Business logic can continue the trace propagation

The key point is that handlers have the flexibility to opt into tracing - the context parameter enables them to participate in the trace chain from the router's entry point through to completion, but they're not required to do so. This gives developers the freedom to integrate with tracing where it makes sense for their use case.

Another important consideration is to distinguish between application-level and message dispatcher-level contexts. This distinction helps in understanding the scope and responsibility of context propagation through different layers of the system.

We could potentially enhance the router's tracing support to make this pattern even more straightforward to implement.

Add context.Context support to StandardRouter message routing #286

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions