[PR #21886] [CLOSED] fix: handle non-numeric timestamp values in chat_message migration #129980

Closed
opened 2026-05-21 13:40:10 -05:00 by GiteaMirror · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/21886
Author: @npuigm
Created: 2/26/2026
Status: Closed

Base: devHead: fix/migration-timestamp-type-coercion


📝 Commits (1)

  • 96636f1 fix: handle non-numeric timestamp values in chat_message migration

📊 Changes

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

View changed files

📝 backend/open_webui/migrations/versions/8452d01d26d7_add_chat_message_table.py (+7 -0)

📄 Description

Summary

The alembic migration 8452d01d26d7_add_chat_message_table (introduced in v0.8.5) crashes when the timestamp field inside chat message JSON data contains a non-numeric string value.

Root cause: The migration reads message.get("timestamp", now) and immediately compares it with > and < against integers (lines 131–135). If timestamp is a string, Python raises:

TypeError: '>' not supported between instances of 'str' and 'int'

This rolls back the entire migration transaction. On the next startup, the app finds an incomplete schema and returns 500 on /api/config, showing users "Open WebUI Backend Required".

How string timestamps get into the database: In our case, an automated security scanner (DAST) injected path-traversal payloads (/etc/passwd, c:/Windows/system.ini, etc.) into the chat API, which were stored verbatim in the timestamp field of 99 chat messages. Any corrupted or manually edited chat data with non-numeric timestamps would trigger the same crash.

Fix

  • Wrap timestamp in int() with a try/except (TypeError, ValueError) before the numeric comparisons
  • On failure, fall back to now — consistent with the existing fallback for out-of-range timestamps
  • This is a 5-line addition with zero impact on valid data paths

Test plan

  • Verified fix locally against a database containing string timestamp values
  • Migration completes successfully after the fix
  • Valid integer and float timestamps are unaffected (int(1234567890) → same value)

🔄 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/21886 **Author:** [@npuigm](https://github.com/npuigm) **Created:** 2/26/2026 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `fix/migration-timestamp-type-coercion` --- ### 📝 Commits (1) - [`96636f1`](https://github.com/open-webui/open-webui/commit/96636f1ecdc1567e0d1b0400d2effae415ce3c5c) fix: handle non-numeric timestamp values in chat_message migration ### 📊 Changes **1 file changed** (+7 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/migrations/versions/8452d01d26d7_add_chat_message_table.py` (+7 -0) </details> ### 📄 Description ## Summary The alembic migration `8452d01d26d7_add_chat_message_table` (introduced in v0.8.5) crashes when the `timestamp` field inside chat message JSON data contains a non-numeric string value. **Root cause:** The migration reads `message.get("timestamp", now)` and immediately compares it with `>` and `<` against integers (lines 131–135). If `timestamp` is a string, Python raises: ``` TypeError: '>' not supported between instances of 'str' and 'int' ``` This rolls back the entire migration transaction. On the next startup, the app finds an incomplete schema and returns 500 on `/api/config`, showing users "Open WebUI Backend Required". **How string timestamps get into the database:** In our case, an automated security scanner (DAST) injected path-traversal payloads (`/etc/passwd`, `c:/Windows/system.ini`, etc.) into the chat API, which were stored verbatim in the `timestamp` field of 99 chat messages. Any corrupted or manually edited chat data with non-numeric timestamps would trigger the same crash. ## Fix - Wrap `timestamp` in `int()` with a `try/except (TypeError, ValueError)` before the numeric comparisons - On failure, fall back to `now` — consistent with the existing fallback for out-of-range timestamps - This is a 5-line addition with zero impact on valid data paths ## Test plan - [x] Verified fix locally against a database containing string timestamp values - [x] Migration completes successfully after the fix - [x] Valid integer and float timestamps are unaffected (`int(1234567890)` → same value) --- <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-05-21 13:40:10 -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#129980