fix(litellm): Set operation name from call type instead of chat fallback

[VihaanAgarwal]

Fixes #6442.

The input callback mapped every call type except embedding/aembedding to chat, so a litellm.image_generation() call showed up in Sentry as chat dall-e-3 with gen_ai.operation.name: chat. Same story for text completions, speech, transcription, rerank and the rest.

This replaces the binary fallback with an explicit table of the call types we can name accurately:

• completion/acompletion -> chat
• text_completion/atext_completion -> text_completion
• embedding/aembedding -> embeddings
• responses/aresponses -> responses

Each maps to its matching OP.GEN_AI_* span op (the constants for text_completion and responses already exist and are used by the langchain and openai integrations).

For everything else, gen_ai.operation.name is simply not set. Recording a guess is what this issue is about, and litellm has 140+ call types (batch, files, assistants, video...), most of which have no semconv equivalent. The raw call type still ends up in the span name (image_generation dall-e-3), so the spans stay identifiable. I kept gen_ai.chat as the span op fallback for unmapped types so those spans keep flowing into the AI views like before; happy to change that if you'd rather they drop out.

One test tweak: test_response_without_usage built callback kwargs without a call_type and asserted the span was named chat ..., which only held because of the fallback. Real callbacks always carry call_type (litellm's Logging.pre_call sets it), so I added "call_type": "completion" to those kwargs rather than special casing a missing key as chat.

Tests cover all eight mapped call types plus the unknown case. The litellm test module passes locally except test_multiple_providers, which errors at setup on current master too (missing optional provider package in my env).

[alexander-alderman-webb]

No data is better than wrong data, so please exit early if the key is not in the dictionary.

[alexander-alderman-webb]

For tests, the expectation is that you use the library like a user would and assert that the correct telemetry was emitted.
The existing tests have prior art for how to achieve this.

[VihaanAgarwal]

Fair points, both addressed. Unknown call types now bail before any span is created, so nothing gets recorded for them. Also replaced the callback-level tests with ones that go through litellm.text_completion / litellm.responses / litellm.image_generation with mocked transports and assert on the captured spans.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b57b7f9. Configure here.}

[cursor]

New ops skip prompt capture

Medium Severity

_CALL_TYPE_OPERATIONS now yields text_completion and responses, but prompt recording still only special-cases embeddings and otherwise reads messages. Those call types take prompt and input, so with include_prompts enabled their inputs are never attached to the span.

Additional Locations (1)

• sentry_sdk/integrations/litellm.py#L39-L49

 

^{Reviewed by Cursor Bugbot for commit b57b7f9. Configure here.}

[sentry]

Bug: The _input_callback returns early for unmapped call_types, preventing span creation and disabling exception capture for litellm calls like image_generation.
_{Severity: MEDIUM}

Suggested Fix

To restore exception capturing for all litellm call types, ensure a span is created even for unmapped types. Consider creating a fallback span with a generic operation, similar to the previous behavior, instead of returning early from _input_callback when a call_type is not found.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: sentry_sdk/integrations/litellm.py#L99-L101

Potential issue: The `_input_callback` returns early for any `litellm` `call_type` not
in `_CALL_TYPE_OPERATIONS`, such as `image_generation` or `speech`. This prevents a
Sentry span from being created for these calls. As a result, if an exception occurs
during one of these unmapped calls, the `_failure_callback` is unable to find a span to
process. It returns immediately, and the exception is not captured by Sentry. This is a
regression that silently disables error reporting for previously-instrumented call
types.

_{Did we get this right? 👍 / 👎 to inform future reviews.}