[duplicate-code] Duplicate Code Pattern: StartProxyForwardSpan Dead Code vs Inline Span Creation in handler.go

[github-actions]

Part of duplicate code analysis: #7509

Summary

StartProxyForwardSpan in internal/tracing/span_helpers.go is dead code. The actual "proxy.backend.forward" span is created inline in internal/proxy/handler.go with a slightly different attribute set (adds semconv.ServerAddressKey). The helper and the inline call are two implementations of the same concept that have drifted apart.

Duplication Details

Pattern: Duplicate "proxy.backend.forward" span creation

• Severity: Low
• Occurrences: 2
• Locations:
  • internal/tracing/span_helpers.go lines 77-86 (unused helper)
  • internal/proxy/handler.go lines 225-233 (live inline creation)

Helper (never called) — span_helpers.go:77:

func StartProxyForwardSpan(ctx context.Context, tracer oteltrace.Tracer, toolName, urlPath string) (context.Context, oteltrace.Span) {
    logTracing.Printf("Starting proxy forward span: toolName=%s, urlPath=%s", toolName, urlPath)
    return tracer.Start(ctx, "proxy.backend.forward",
        oteltrace.WithAttributes(
            semconv.URLPathKey.String(urlPath),
            tracing.GenAIToolName.String(toolName),
        ),
        oteltrace.WithSpanKind(oteltrace.SpanKindClient),
    )
}

Live inline creation — handler.go:225:

fwdCtx, fwdSpan := h.GetTracer().Start(ctx, "proxy.backend.forward",
    oteltrace.WithAttributes(
        semconv.URLPathKey.String(r.URL.Path),
        semconv.ServerAddressKey.String(h.server.upstreamHost()),  // extra attribute
        tracing.GenAIToolName.String(toolName),
    ),
    oteltrace.WithSpanKind(oteltrace.SpanKindClient),
)

The helper omits semconv.ServerAddressKey, which is why it was never adopted.

Impact Analysis

• Maintainability: Dead code misleads future contributors into thinking the helper is in use; the inline version may diverge further as attributes are added
• Bug Risk: If someone calls StartProxyForwardSpan, the span will be missing ServerAddress, producing incomplete telemetry
• Code Bloat: ~10 lines of unreachable code

Refactoring Recommendations

Option A (recommended): Add serverAddress parameter and use the helper

// Updated helper
func StartProxyForwardSpan(ctx context.Context, tracer oteltrace.Tracer, toolName, urlPath, serverAddress string) (context.Context, oteltrace.Span) {
    logTracing.Printf("Starting proxy forward span: toolName=%s, urlPath=%s", toolName, urlPath)
    return tracer.Start(ctx, "proxy.backend.forward",
        oteltrace.WithAttributes(
            semconv.URLPathKey.String(urlPath),
            semconv.ServerAddressKey.String(serverAddress),
            GenAIToolName.String(toolName),
        ),
        oteltrace.WithSpanKind(oteltrace.SpanKindClient),
    )
}

Then in handler.go:

fwdCtx, fwdSpan := tracing.StartProxyForwardSpan(ctx, h.GetTracer(), toolName, r.URL.Path, h.server.upstreamHost())

Option B: Delete StartProxyForwardSpan if the helper pattern isn't needed, keeping the inline version as-is.

Implementation Checklist

• Choose Option A or B
• If A: update StartProxyForwardSpan signature, update handler.go call site
• If B: delete StartProxyForwardSpan from span_helpers.go
• Run make test to verify nothing is broken
• Confirm go vet (dead-code check) passes

Parent Issue

See parent analysis report: #7509
Related to #7509

Generated by Duplicate Code Detector · 1.9K AIC · ⊞ 35.7K · ◷

• expires on Jun 21, 2026, 3:49 AM UTC