[Fix] UI - Logs: Empty Filter Results Show Stale Data

[yuneng-jiang]

Summary

Problem

When a backend filter (e.g. Key Alias) returns an empty result set ({data: [], total: 0}), the logs table continues showing stale unfiltered data instead of an empty table.

Fix

Removed the .length > 0 guard in the filteredLogs memo in log_filter_logic.tsx. The previous logic fell back to unfiltered logs whenever backendFilteredLogs.data was an empty array, which is incorrect — an empty result is a valid filter result and should be displayed as such.

Testing

• Apply a filter (e.g. Key Alias) that matches no logs → table now correctly shows no results
• Apply a filter that matches logs → table shows matching results as before
• Clear filters → table returns to unfiltered view

Type

🐛 Bug Fix

Screenshot

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Mar 16, 2026 11:29pm

[greptile-apps]

Greptile Summary

This PR bundles three distinct bug fixes and associated test coverage under a v1.82.3 release:

1. UI – Empty filter results show stale data (log_filter_logic.tsx): The .length > 0 guard in filteredLogs was causing the table to fall back to unfiltered logs when the backend returned an empty result set. The fix removes the guard so data: [] is treated as a valid result.
2. Cost calculator – Custom per-request pricing returns 0 (cost_calculator.py): When custom_pricing=True and a router_model_id is present in model_cost but has no actual pricing fields, the old code still selected router_model_id, yielding a zero cost. The fix adds a pricing-field existence check before preferring router_model_id.
3. Proxy CLI – TypeError with single-string callbacks (proxy_cli.py): _maybe_setup_prometheus_multiproc_dir assumed callbacks were always lists; the fix normalises string values to single-element lists before concatenation.

Each fix ships with a targeted test (see test_cost_calculator.py, test_prometheus_cleanup.py, and the corrected test_proxy_cli.py). The PR also fixes a missing mock in test_mcp_server.py and updates an example custom-auth file to set user_role.

Key items to note:

• The cost_calculator.py pricing guard only checks input_cost_per_token and input_cost_per_second; models priced exclusively by audio, image, or character tokens would still be misclassified.
• test_router_utils.py acquires a @pytest.mark.flaky(retries=3) decorator — this treats the symptom of a timing race rather than fixing the underlying non-determinism.
• During the brief window between a filter being applied and the backend response arriving, the UI still returns stale unfiltered logs (the else branch). This is a smaller form of the original issue and may be worth a follow-up.

Confidence Score: 4/5

• PR is safe to merge — all three fixes are well-scoped, backed by tests, and do not introduce backwards-incompatible changes.
• Each fix is narrowly targeted and fully tested. The one point deducted is for the incomplete pricing-field guard in cost_calculator.py which could silently yield wrong costs for audio/image-only priced models with custom per-request pricing, and for the @pytest.mark.flaky decorator masking a timing race in CI.
• litellm/cost_calculator.py — the pricing-existence check should cover additional input cost field types to be robust.

Important Files Changed

Filename	Overview
ui/litellm-dashboard/src/components/view_logs/log_filter_logic.tsx	Core bug fix: removes .length > 0 guard so empty backend filter results are correctly returned instead of falling back to stale unfiltered logs.
litellm/cost_calculator.py	Bug fix for custom pricing: only use router_model_id when its model_cost entry has actual pricing data; otherwise fall back to model name. Check covers input_cost_per_token and input_cost_per_second but may miss audio/image pricing fields.
litellm/proxy/proxy_cli.py	Bug fix: normalizes callback config values from string to list before concatenation, preventing TypeError when callbacks are specified as a single string.
tests/test_litellm/test_cost_calculator.py	New regression test covering the per-request custom pricing fix. Clearly documents the bug scenario and asserts correct model selection.
tests/local_testing/test_router_utils.py	Added @pytest.mark.flaky(retries=3) and increased sleep to 2s — masks a timing-dependent flakiness rather than fixing the root cause.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User applies backend filter] --> B{hasBackendFilters?}
    B -- No --> C[Return clientDerivedFilteredLogs]
    B -- Yes --> D{backendFilteredLogs\n&& backendFilteredLogs.data?}
    D -- Yes\n'data' can be empty array --> E[Return backendFilteredLogs\n✅ including empty results]
    D -- No\nstill loading --> F[Return logs\nunfiltered fallback]

    style E fill:#90EE90
    style F fill:#FFD700

    subgraph "OLD behaviour"
        G{data.length > 0?}
        G -- No: data is empty array --> H[Return logs\n❌ stale unfiltered data]
        G -- Yes --> I[Return backendFilteredLogs]
    end

Loading

Comments Outside Diff (1)

1. ui/litellm-dashboard/src/components/view_logs/log_filter_logic.tsx, line 228-243 (link)

   Loading-state gap: stale logs still flash while the request is in-flight

   After the fix, the path is:

   1. User applies a filter → hasBackendFilters becomes true
   2. backendFilteredLogs is still null/undefined (request pending)
   3. The else branch returns logs (the unfiltered data)
   4. When the response arrives the table switches to the filtered result (or empty)

   This means there is a window where users still see the previous unfiltered logs while the backend request is pending — the original stale-data symptom in a narrower form. The fix is correct for the empty-result case, but if a loader/spinner is not already shown during step 2–3, consider returning null / a loading sentinel instead of the raw logs so the UI can render a skeleton or empty state immediately on filter application.

_{Last reviewed commit: 57bba3b}

[greptile-apps]

Pricing check may miss non-token cost types

The guard for whether the router_model_id entry has real pricing only checks input_cost_per_token and input_cost_per_second. There are other pricing dimensions in model_prices_and_context_window.json — e.g. input_cost_per_audio_token, input_cost_per_image_token, input_cost_per_character — that would cause the condition to evaluate to False even when the entry does have meaningful custom pricing, silently falling back to the model name and potentially returning the wrong cost.

Consider broadening the guard to cover all known input cost fields:

PRICING_FIELDS = (
    "input_cost_per_token",
    "input_cost_per_second",
    "input_cost_per_audio_token",
    "input_cost_per_image_token",
    "input_cost_per_character",
)
if any(entry.get(f) is not None for f in PRICING_FIELDS):
    return_model = router_model_id
else:
    return_model = model

[greptile-apps]

@pytest.mark.flaky masks a timing-dependent test

Adding retries=3, delay=1 addresses the symptom but not the root cause. The test relies on a Redis/in-memory counter being updated after router.acompletion() completes — a time-based race condition. The sleep increase from 1 s → 2 s is a better signal here, but retrying a flaky test in a shared CI environment is still fragile and can hide real regressions.

Consider instead waiting on the side-effect deterministically, e.g. polling get_model_group_usage until it reflects the expected value, or mocking the underlying cache update.