feat: change guardrail_information to list type

[uc4w6c]

Title

change guardrail_information to list type to support displaying multiple guardrails

Relevant issues

#N/A

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
• [] I have added a screenshot of my new test passing locally
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem

Type

🆕 New Feature
📖 Documentation
✅ Test

Changes

This change updates StandardLoggingGuardrailInformation to a list type, enabling visualization of multiple guardrails applied within a single request.

What’s changed
StandardLoggingGuardrailInformation is now returned as an array. The UI has been updated to display multiple guardrail entries when present.

Not included (to be addressed next)
There is an existing issue where StandardLoggingGuardrailInformation set during post_call is not passed through to logging. This PR does not address that behavior. I plan to handle this in a follow-up PR.

---

Note

Switches guardrail_information to a list and updates logging, integrations, spend tracking, and UI to handle multiple guardrail entries with aggregated status/latency.

• Logging spec & core:
  • Change guardrail_information to Optional[list[StandardLoggingGuardrailInformation]] across StandardLoggingPayload, proxy types, spend logs metadata, and utils.
  • Update guardrail_status literals to "success" | "guardrail_intervened" | "guardrail_failed_to_respond" | "not_run" and derive status from any non-not_run entry.
  • Modify _get_status_fields to read lists; keep response time/cost logic intact.
• Guardrails:
  • CustomGuardrail: append multiple standard_logging_guardrail_information entries; handle existing dict→list migration.
• Integrations:
  • Datadog: include guardrail_information list in metadata; sum guardrail durations for guardrail_overhead_time_ms.
  • Langfuse: create a span per guardrail entry; validate list shape.
  • OpenTelemetry: create a span per guardrail entry; guard against empty/non-list inputs.
• Spend tracking:
  • Propagate list-typed guardrail info into spend logs payload.
• UI (Dashboard):
  • GuardrailViewer redesigned to render multiple entries and show aggregated status/masked counts.
  • Log details view updated to accept array or single item and compute totals.
• Docs & Tests:
  • Update docs to new types and status literals.
  • Add/adjust tests for Datadog, OpenTelemetry, and CustomGuardrail list handling.

^{Written by Cursor Bugbot for commit 9a7e5a1. This will update automatically on new commits. Configure here.}

[vercel]

@uc4w6c is attempting to deploy a commit to the CLERKIEAI Team on Vercel.

A member of the Team first needs to authorize it.

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Bug: Guardrail data misprocessed with single dict input

The Datadog and OpenTelemetry integrations expect guardrail_information to be a list. When a single dictionary is provided, the code iterates over its keys, leading to guardrail data being incorrectly processed or silently omitted from logs and traces. This impacts duration calculations and span creation.

Additional Locations (1)

• litellm/integrations/opentelemetry.py#L783-L788