[PR #23322] [CLOSED] fix: normalize usage keys on save in ChatMessages.upsert_message #27147

Closed
opened 2026-04-20 06:54:14 -05:00 by GiteaMirror · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/23322
Author: @smorello87
Created: 4/1/2026
Status: Closed

Base: devHead: fix/normalize-usage-on-save


📝 Commits (10+)

📊 Changes

1 file changed (+4 additions, -0 deletions)

View changed files

📝 backend/open_webui/models/chat_messages.py (+4 -0)

📄 Description

Pull Request Checklist

  • Target branch: Verify that the pull request targets the dev branch.
  • Description: Provided below.
  • Changelog: Provided below.
  • Documentation: No user-facing behavior changes; this is an internal normalization fix.
  • Dependencies: No new dependencies. Reuses existing normalize_usage() from utils/response.py.
  • Testing: Tested on production PostgreSQL 16.3 deployment (~500 users) since v0.8.0 through v0.8.12 as a build-time patch. Verified analytics dashboard correctly displays token usage for all providers (OpenRouter, Bedrock, Ollama) after applying.
  • Agentic AI Code: This fix was authored and tested by a human. We have been running this exact patch in production since February 2026.
  • Code review: Self-reviewed. The change is 4 lines: 1 import + normalization calls in both update and insert paths.
  • Design & Architecture: No new settings or UI changes. Reuses existing internal function.
  • Git Hygiene: Single atomic commit, one logical change.
  • Title Prefix: fix:

Changelog Entry

Description

OpenAI-compatible APIs (OpenRouter, etc.) return token usage as prompt_tokens / completion_tokens, but the analytics queries in get_token_usage_by_model and get_token_usage_by_user read input_tokens / output_tokens. The existing normalize_usage() function in utils/response.py handles this mapping but is only called in the streaming middleware — the normalized result never reaches the database save path through ChatMessages.upsert_message().

This adds normalize_usage() calls in both the update and insert branches of upsert_message(), ensuring all usage data is normalized before saving regardless of code path.

Added

  • N/A

Changed

  • N/A

Deprecated

  • N/A

Removed

  • N/A

Fixed

  • Token usage analytics showing 0 for most messages because chat_message.usage was saved with OpenAI-format keys (prompt_tokens/completion_tokens) but analytics queries read Anthropic-format keys (input_tokens/output_tokens). Now both key formats are always present.

Security

  • N/A

Breaking Changes

  • N/A

Additional Information

  • Fixes #21347 (Bug 2: usage key name mismatch)
  • Related: #21675 (analytics enhancements)
  • This fix only affects new messages going forward. Existing records can be backfilled with:
-- PostgreSQL
UPDATE chat_message
SET usage = usage::jsonb || jsonb_build_object(
    'input_tokens', (usage->>'prompt_tokens')::int,
    'output_tokens', (usage->>'completion_tokens')::int)
WHERE usage->>'prompt_tokens' IS NOT NULL
  AND usage->>'input_tokens' IS NULL;

How it was tested

  1. Applied this exact fix as a build-time patch on our CUNY production deployment (PostgreSQL 16.3, ~500 users, OpenRouter + Bedrock + Ollama providers)
  2. Sent test messages through each provider
  3. Queried chat_message table directly to confirm both prompt_tokens and input_tokens keys are present in saved usage JSON
  4. Verified analytics dashboard (Admin → Dashboard) correctly displays non-zero token counts for all users and models
  5. Running continuously since v0.8.0 through v0.8.12 with no issues

Screenshots or Videos

Before fix — analytics shows 0 tokens (keys missing):

SELECT usage->>'prompt_tokens', usage->>'input_tokens' FROM chat_message LIMIT 5;
 prompt_tokens | input_tokens
---------------+--------------
 150           | (null)        ← analytics reads this column, gets NULL
 2048          | (null)
 89            | (null)

After fix — both key formats present:

SELECT usage->>'prompt_tokens', usage->>'input_tokens' FROM chat_message LIMIT 5;
 prompt_tokens | input_tokens
---------------+--------------
 150           | 150           ← analytics now reads correct value
 2048          | 2048
 89            | 89

Contributor License Agreement


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-webui/pull/23322 **Author:** [@smorello87](https://github.com/smorello87) **Created:** 4/1/2026 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `fix/normalize-usage-on-save` --- ### 📝 Commits (10+) - [`fe6783c`](https://github.com/open-webui/open-webui/commit/fe6783c16699911c7be17392596d579333fb110c) Merge pull request #19030 from open-webui/dev - [`fc05e0a`](https://github.com/open-webui/open-webui/commit/fc05e0a6c5d39da60b603b4d520f800d6e36f748) Merge pull request #19405 from open-webui/dev - [`e3faec6`](https://github.com/open-webui/open-webui/commit/e3faec62c58e3a83d89aa3df539feacefa125e0c) Merge pull request #19416 from open-webui/dev - [`9899293`](https://github.com/open-webui/open-webui/commit/9899293f050ad50ae12024cbebee7e018acd851e) Merge pull request #19448 from open-webui/dev - [`140605e`](https://github.com/open-webui/open-webui/commit/140605e660b8186a7d5c79fb3be6ffb147a2f498) Merge pull request #19462 from open-webui/dev - [`6f1486f`](https://github.com/open-webui/open-webui/commit/6f1486ffd0cb288d0e21f41845361924e0d742b3) Merge pull request #19466 from open-webui/dev - [`d95f533`](https://github.com/open-webui/open-webui/commit/d95f533214e3fe5beb5e41ec1f349940bc4c7043) Merge pull request #19729 from open-webui/dev - [`a727153`](https://github.com/open-webui/open-webui/commit/a7271532f8a38da46785afcaa7e65f9a45e7d753) 0.6.43 (#20093) - [`6adde20`](https://github.com/open-webui/open-webui/commit/6adde203cd292a9e3af9c64a2ae36b603fed096a) Merge pull request #20394 from open-webui/dev - [`f9b0534`](https://github.com/open-webui/open-webui/commit/f9b0534e0c442631d1cb7205169588b9b6204179) Merge pull request #20522 from open-webui/dev ### 📊 Changes **1 file changed** (+4 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/models/chat_messages.py` (+4 -0) </details> ### 📄 Description # Pull Request Checklist - [x] **Target branch:** Verify that the pull request targets the `dev` branch. - [x] **Description:** Provided below. - [x] **Changelog:** Provided below. - [ ] **Documentation:** No user-facing behavior changes; this is an internal normalization fix. - [x] **Dependencies:** No new dependencies. Reuses existing `normalize_usage()` from `utils/response.py`. - [x] **Testing:** Tested on production PostgreSQL 16.3 deployment (~500 users) since v0.8.0 through v0.8.12 as a build-time patch. Verified analytics dashboard correctly displays token usage for all providers (OpenRouter, Bedrock, Ollama) after applying. - [x] **Agentic AI Code:** This fix was authored and tested by a human. We have been running this exact patch in production since February 2026. - [x] **Code review:** Self-reviewed. The change is 4 lines: 1 import + normalization calls in both update and insert paths. - [x] **Design & Architecture:** No new settings or UI changes. Reuses existing internal function. - [x] **Git Hygiene:** Single atomic commit, one logical change. - [x] **Title Prefix:** `fix:` # Changelog Entry ### Description OpenAI-compatible APIs (OpenRouter, etc.) return token usage as `prompt_tokens` / `completion_tokens`, but the analytics queries in `get_token_usage_by_model` and `get_token_usage_by_user` read `input_tokens` / `output_tokens`. The existing `normalize_usage()` function in `utils/response.py` handles this mapping but is only called in the streaming middleware — the normalized result never reaches the database save path through `ChatMessages.upsert_message()`. This adds `normalize_usage()` calls in both the **update** and **insert** branches of `upsert_message()`, ensuring all usage data is normalized before saving regardless of code path. ### Added - N/A ### Changed - N/A ### Deprecated - N/A ### Removed - N/A ### Fixed - Token usage analytics showing 0 for most messages because `chat_message.usage` was saved with OpenAI-format keys (`prompt_tokens`/`completion_tokens`) but analytics queries read Anthropic-format keys (`input_tokens`/`output_tokens`). Now both key formats are always present. ### Security - N/A ### Breaking Changes - N/A --- ### Additional Information - Fixes #21347 (Bug 2: usage key name mismatch) - Related: #21675 (analytics enhancements) - This fix only affects **new** messages going forward. Existing records can be backfilled with: ```sql -- PostgreSQL UPDATE chat_message SET usage = usage::jsonb || jsonb_build_object( 'input_tokens', (usage->>'prompt_tokens')::int, 'output_tokens', (usage->>'completion_tokens')::int) WHERE usage->>'prompt_tokens' IS NOT NULL AND usage->>'input_tokens' IS NULL; ``` ### How it was tested 1. Applied this exact fix as a build-time patch on our CUNY production deployment (PostgreSQL 16.3, ~500 users, OpenRouter + Bedrock + Ollama providers) 2. Sent test messages through each provider 3. Queried `chat_message` table directly to confirm both `prompt_tokens` and `input_tokens` keys are present in saved usage JSON 4. Verified analytics dashboard (Admin → Dashboard) correctly displays non-zero token counts for all users and models 5. Running continuously since v0.8.0 through v0.8.12 with no issues ### Screenshots or Videos Before fix — analytics shows 0 tokens (keys missing): ``` SELECT usage->>'prompt_tokens', usage->>'input_tokens' FROM chat_message LIMIT 5; prompt_tokens | input_tokens ---------------+-------------- 150 | (null) ← analytics reads this column, gets NULL 2048 | (null) 89 | (null) ``` After fix — both key formats present: ``` SELECT usage->>'prompt_tokens', usage->>'input_tokens' FROM chat_message LIMIT 5; prompt_tokens | input_tokens ---------------+-------------- 150 | 150 ← analytics now reads correct value 2048 | 2048 89 | 89 ``` ### Contributor License Agreement - [x] By submitting this pull request, I confirm that I have read and fully agree to the [Contributor License Agreement (CLA)](https://github.com/open-webui/open-webui/blob/main/CONTRIBUTOR_LICENSE_AGREEMENT), and I am providing my contributions under its terms. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-20 06:54:14 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#27147