fix(ui): keep untimed guardrail entries on the request lifecycle - #41374

TLDR

Problem this solves:

• Guardrails that report no timing vanished from the log drawer's lifecycle
• The whole four-row Request Lifecycle panel renders empty
• Pre-existing shape: the recorder defaults timing to None

How it solves it:

• An entry stays on the lifecycle when it is timed or when it ran
• not_run keeps the exclusion fix(guardrails): record not_run evaluation when scoping leaves nothing to scan #39050 added, untouched
• Missing offsets render as an em dash, not a fabricated T+0ms

User Flow

Before: an admin looking at a log for a guardrail that reports no timing gets an empty Request Lifecycle panel

1. They send POST http://localhost:4010/v1/chat/completions with a guardrail enabled that records its decision without start/end times (the conduct guardrail does this today)
2. They open http://localhost:4010/ui/?page=logs and click the request's row
3. The drawer says "1 guardrail evaluated" and the guardrail is named under Request Details
4. The "Request Lifecycle" heading renders with nothing under it, so the panel jumps straight to Evaluation Details, and they cannot see which phase the guardrail ran in

After: the same log shows the lifecycle again, with no invented timings

1. They send the same POST http://localhost:4010/v1/chat/completions
2. They open http://localhost:4010/ui/?page=logs and click the request's row
3. The drawer still says "1 guardrail evaluated"
4. Request Lifecycle lists "Request received", "Pre-call guardrail: PASSED", "LLM call" and "Response returned", each showing an em dash where an elapsed offset would be, because this guardrail never reported one

Relevant issues

Affected release

Linear ticket

Pre-Submission checklist

• I have added meaningful tests
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Screenshots / Proof of Fix

Both legs were captured by driving the real Admin UI, served by a live proxy on :4010 against its own Postgres, opening the same real log row from one real OpenAI call. The guardrail is a custom guardrail that records its decision without timing, which is the shape the conduct guardrail emits today.

Shared setup, config.yaml:

model_list:
  - model_name: gpt-4o-mini
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

guardrails:
  - guardrail_name: "conduct-style-untimed"
    litellm_params:
      guardrail: untimed_guardrail.UntimedPreCallGuardrail
      mode: "pre_call"
      default_on: true

general_settings:
  store_prompts_in_spend_logs: true

untimed_guardrail.py, next to the config and on PYTHONPATH:

class UntimedPreCallGuardrail(CustomGuardrail):
    async def async_pre_call_hook(self, user_api_key_dict, cache, data, call_type):
        self.add_standard_logging_guardrail_information_to_request_data(
            guardrail_json_response={"verdict": "allow", "rule_id": "demo-rule"},
            request_data=data,
            guardrail_status="success",
        )
        return data

The one request both legs read back:

curl -sS -X POST http://127.0.0.1:4010/v1/chat/completions \
  -H "Authorization: Bearer sk-1234" -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Say the single word: lifecycle"}]}'
lifecycle

which stored exactly the shape this PR is about:

[{"duration": null, "end_time": null, "start_time": null,
  "guardrail_mode": "pre_call", "guardrail_name": "conduct-style-untimed",
  "guardrail_status": "success"}]

Before (174c1ac)

1. Open http://127.0.0.1:4010/ui/?page=logs, search the request id, click the row, scroll to Request Lifecycle
2. The heading is there and the panel below it is empty, reading the rendered rows out of the live page:

{ lifecycleHeadingPresent: true, rowCount: 0, rows: [], header: "1 guardrail evaluated" }

After (51a243e)

1. Open http://127.0.0.1:4010/ui/?page=logs, search the same request id, click the row, scroll to Request Lifecycle
2. All four rows are back, each with an em dash in place of an offset this guardrail never reported:

{ rowCount: 4, header: "1 guardrail evaluated", rows: [
  "Request received | —",
  "Pre-call guardrail: conduct-style-untimed | PASSED | —",
  "LLM call | —",
  "Response returned | —" ] }

3. The same two tests are red on the base component and green here, with every other test in the file untouched and passing on both legs:

$ npx vitest run src/components/view_logs/GuardrailViewer/GuardrailViewer.test.tsx
Tests  2 failed | 15 passed (17)   # base GuardrailViewer.tsx, this PR's tests
Tests  17 passed (17)              # this PR

Type

🐛 Bug Fix

Caveats

Low

• A guardrail that reports no timing now shows an em dash where an offset would be, rather than being hidden
• not_run entries that do carry timing still appear, exactly as they do today; this PR does not change that

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR