Skip to content

refactor(chat-ui): reuse shared LogEntry type in logs panel - #33858

Open
devin-ai-integration[bot] wants to merge 1 commit into
litellm_internal_stagingfrom
litellm_chat_logs_shared_type
Open

refactor(chat-ui): reuse shared LogEntry type in logs panel#33858
devin-ai-integration[bot] wants to merge 1 commit into
litellm_internal_stagingfrom
litellm_chat_logs_shared_type

Conversation

@devin-ai-integration

Copy link
Copy Markdown
Contributor

Relevant issues

Follow-up to #33829 (merged), addressing review feedback from @ryan-crabbe-berri

Linear ticket

Pre-Submission checklist

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

  • I have added meaningful tests
  • My PR passes all CI/CD checks (e.g., lint, format, unit tests)
  • 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

Type-only refactor with no runtime or behavior change; the existing LogsPanel.test.tsx suite (user scoping, row/empty/error states, lazy detail load, proxy_server_request fallback) still passes and frontend-lint / build-ui stay green

Type

🧹 Refactoring

Changes

Follow-up to review feedback on #33829: the chat Logs panel hand-rolled its own LogRow interface for the /spend/logs/ui rows. This reuses the shared LogEntry type that the main Spend Logs UI already defines in view_logs/columns.tsx, so the row shape lives in one place instead of being duplicated

-interface LogRow { request_id: string; model: string; status?: string; ... }
+import type { LogEntry } from "../view_logs/columns";

Note on why not the generated schema.d.ts type directly: the reviewer asked about pulling from schema.d.ts. The generated components["schemas"]["LiteLLM_SpendLogs"] exists but does not fully fit this table today; it omits status, request_duration_ms, and custom_llm_provider (which the endpoint returns and the table renders), and it types the /spend/logs/ui response as a bare LiteLLM_SpendLogs[] rather than the paginated { data, total, page, page_size, total_pages } wrapper the endpoint actually returns. That mismatch is exactly why the main log UI maintains the hand-written LogEntry. Reusing LogEntry removes the duplication now; making schema.d.ts the single source of truth would additionally require fixing the backend Pydantic response model (add the missing fields, model the pagination wrapper) and regenerating types, which is a larger, separate change

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

Link to Devin session: https://app.devin.ai/sessions/d8f28b85a07e42fba149e7e51169bf0a
Requested by: @krrish-berri-2

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
@devin-ai-integration

Copy link
Copy Markdown
Contributor Author

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

  • Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
  • Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

  • Disable automatic comment, CI, and merge conflict monitoring

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@greptile-apps

greptile-apps Bot commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR eliminates the duplicate LogRow interface in LogsPanel.tsx by importing and reusing the shared LogEntry type already defined in view_logs/columns.tsx. It is a pure type-level refactor with no runtime or behavioral change.

  • The old LogRow is a strict subset of LogEntry; every field LogsPanel.tsx reads (request_id, model, custom_llm_provider, status, spend, total_tokens, prompt_tokens, completion_tokens, startTime, endTime, request_duration_ms) exists in LogEntry with identical or compatible types.
  • LogEntry adds required fields not previously declared in LogRow (api_key, team_id, model_id, call_type, cache_hit, messages, response), but both panels hit the same /spend/logs/ui endpoint, so the runtime data already contains those fields.

Confidence Score: 5/5

Safe to merge — the change is confined to a single TypeScript import and interface substitution with no runtime effect.

Every field accessed by LogsPanel.tsx is present in LogEntry with compatible types. The removed LogRow was a strict subset of LogEntry, so no consumer is narrowed in a way that would cause a type error or behavioral difference. The only material difference is that LogEntry carries additional required fields the old interface omitted, but those fields are already present in the actual API responses since both panels share the same endpoint.

No files require special attention.

Important Files Changed

Filename Overview
ui/litellm-dashboard/src/components/chat/LogsPanel.tsx Removes local LogRow interface and replaces all references with the shared LogEntry type from view_logs/columns; no runtime or behavior change

Reviews (1): Last reviewed commit: "refactor(chat-ui): reuse shared LogEntry..." | Re-trigger Greptile

@codspeed-hq

codspeed-hq Bot commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

Merging this PR will not alter performance

✅ 31 untouched benchmarks


Comparing litellm_chat_logs_shared_type (8f85e7d) with litellm_internal_staging (e238e89)1

Open in CodSpeed

Footnotes

  1. No successful run was found on litellm_internal_staging (d495da4) during the generation of this report, so e238e89 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants