fix(otel): reduce span attribute duplication and fix orphaned guardrail traces

[Harshit28j]

Summary

Fixes 4 OpenTelemetry tracing issues related to span attribute duplication and missing trace data:

• Issue fix(otel): reduce span attribute duplication and fix orphaned guardrail traces #3: Removed redundant attributes from raw_gen_ai_request spans
• Issue chore: regenerate poetry.lock to match pyproject.toml #4: Eliminated full attribute duplication on litellm_proxy_request when child span exists
• Issue Update main.py BerriAI/litellm#5: Prevented orphaned guardrail traces by validating parent context
• Issue Added OpenRouter support BerriAI/litellm#8: Added fallback to litellm_call_id for responses without native id field (embeddings, image generation)

Changes

1. set_raw_request_attributes(): Removed initial set_attributes() call to avoid duplicating all parent span data. Now only sets provider-specific llm.{provider}.{param} attributes.

2. Proxy span optimization: Created _set_proxy_span_minimal_attributes() to set only model, call_type, and response.id on proxy request spans instead of copying all attributes from child litellm_request span.

3. Guardrail span protection: Added context is None check at start of _create_guardrail_span() to prevent creation of orphaned root-level traces.

4. Response ID coverage: Modified OTEL span attribute setting to fall back to litellm_call_id when response_obj.get("id") returns None (for EmbeddingResponse and ImageResponse types).

Test Plan

✅ Updated existing guardrail span tests with valid parent context
✅ Added new test verifying guardrail spans are not created without parent context
✅ OTEL unit tests: 71 passed (2 previously failing guardrail tests now pass)

🤖 Generated with Claude Code

In general, to fix untrusted URL redirection you should not redirect to arbitrary user-provided URLs. Instead, either (a) maintain a whitelist of allowed redirect URIs (for example, pre-registered per client_id or server_id) and ensure the provided redirect_uri matches one of them, or (b) restrict redirects to same-origin or relative paths by validating the URL structure (e.g., no external host). For OAuth-like flows, the standard approach is to validate that the incoming redirect_uri exactly matches one of the URIs registered for that client.

The least-invasive fix here is to restrict redirect_uri to be either a relative URL (no scheme/host) or, if absolute, to share the same scheme/host/port as the current request (same-origin). That maintains flexibility (callers can still specify paths and query strings) without allowing redirection to arbitrary external domains. We can also treat state as a plain value in the query string, which is already safely encoded by urlencode; the primary vulnerability is the host of the redirect target, not embedding state.

Concretely, in byok_authorize_post (lines 629–676):

1. Parse the redirect_uri with urlparse.
2. If it is absolute (has a scheme), require that its scheme is http or https and that its netloc matches the current request’s base URL host (we can derive this via the existing get_request_base_url(request) helper or directly from request.url).
3. If it is relative (no scheme and no netloc), normalize it to start with / and treat it as a path relative to the current origin.
4. Build the final redirect URL by combining a trusted base (from get_request_base_url(request)) with the validated/normalized path and query parameters.
5. Use this trusted location for RedirectResponse.

This preserves existing functionality (clients can still choose where within this site to be redirected and still get their state back) while preventing open redirects to attacker-controlled domains.