github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 06:03:26 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #20563] issue: Functions: chat_id is not reliably available in function pipelines/manifolds (metadata.chat_id missing in some internal/task calls) #19225

New Issue
Closed
opened 2026-04-20 01:35:10 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-20 01:35:10 -05:00
Owner
Copy Link

Originally created by @slashdc on GitHub (Jan 11, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20563

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

0.7.2

Ollama Version (if applicable)

No response

Operating System

ubuntu 22.04

Browser (if applicable)

No response

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

  • For any function/manifold invocation that originates from a specific chat, the backend always includes a stable chat identifier in the request payload (e.g. metadata.chat_id), so the function can receive it as __chat_id__ (when present in the pipe() signature).
  • Internal/task-related invocations (e.g. title generation / wrapper prompts like ### Task:) that are still tied to a chat should also include the same chat_id, so stateful functions can reliably keep “1 chat = 1 runtime/runlog”.

Actual Behavior

  • chat_id is not reliably available in all invocations.
  • Some internal/task/wrapper calls appear to omit metadata.chat_id, which results in __chat_id__ = None inside the function even when the call is effectively associated with an existing chat.
  • This breaks stable per-chat persistence for stateful functions: it can create new runtimes/runlogs unexpectedly and makes correct chat isolation hard or impossible.

Steps to Reproduce

  1. Create a minimal Function/Manifold with a pipe() signature that includes __chat_id__ and logs the received values (e.g. __chat_id__, __task__, __message_id__, __session_id__, and body.get("metadata") if present).
  2. Use OpenWebUI Chat and send a normal user message (observe __chat_id__ is present when metadata.chat_id is included).
  3. Trigger internal/task-related behavior (examples: automatic title generation, query generation, or any wrapper prompt invocation where the last “user” message content starts with ### Task:).
  4. Observe that some invocations reach the function with missing metadata.chat_id, causing __chat_id__ to be empty/None.

Logs & Screenshots

  • Example symptom from the chat UI: the function emits progress/status lines (e.g. “loading state…”, “Searching…”) but then creates a fresh runtime/runlog (“Created new runtime for this chat”) because the invocation lacks a stable chat_id.
  • If needed, I can attach a short function log output showing side-by-side calls where __chat_id__ is present vs missing for internal/task invocations.

Additional Information

  • __chat_id__ is only passed into the function when the parameter exists in the pipe() signature; this is fine. The problem is that metadata.chat_id is not consistently present for all invocations that come from a chat context.
  • For stateful/manifold functions that persist data per chat, a stable chat identifier is required to prevent state fragmentation and avoid cross-chat state mixing.
  • Suggested fix: ensure the backend always attaches metadata.chat_id for any function invocation initiated from a chat context (including internal/task routes/wrapper prompts). If some invocations are truly not chat-scoped, it would help to clearly mark them and avoid invoking chat-bound functions, or provide a stable conversation/session identifier.
Originally created by @slashdc on GitHub (Jan 11, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20563 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version 0.7.2 ### Ollama Version (if applicable) _No response_ ### Operating System ubuntu 22.04 ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior - For any function/manifold invocation that originates from a specific chat, the backend always includes a stable chat identifier in the request payload (e.g. `metadata.chat_id`), so the function can receive it as `__chat_id__` (when present in the `pipe()` signature). - Internal/task-related invocations (e.g. title generation / wrapper prompts like `### Task:`) that are still tied to a chat should also include the same `chat_id`, so stateful functions can reliably keep “1 chat = 1 runtime/runlog”. ### Actual Behavior - `chat_id` is not reliably available in all invocations. - Some internal/task/wrapper calls appear to omit `metadata.chat_id`, which results in `__chat_id__ = None` inside the function even when the call is effectively associated with an existing chat. - This breaks stable per-chat persistence for stateful functions: it can create new runtimes/runlogs unexpectedly and makes correct chat isolation hard or impossible. ### Steps to Reproduce 1. Create a minimal Function/Manifold with a `pipe()` signature that includes `__chat_id__` and logs the received values (e.g. `__chat_id__`, `__task__`, `__message_id__`, `__session_id__`, and `body.get("metadata")` if present). 2. Use OpenWebUI Chat and send a normal user message (observe `__chat_id__` is present when `metadata.chat_id` is included). 3. Trigger internal/task-related behavior (examples: automatic title generation, query generation, or any wrapper prompt invocation where the last “user” message content starts with `### Task:`). 4. Observe that some invocations reach the function with missing `metadata.chat_id`, causing `__chat_id__` to be empty/None. ### Logs & Screenshots - Example symptom from the chat UI: the function emits progress/status lines (e.g. “loading state…”, “Searching…”) but then creates a fresh runtime/runlog (“Created new runtime for this chat”) because the invocation lacks a stable `chat_id`. - If needed, I can attach a short function log output showing side-by-side calls where `__chat_id__` is present vs missing for internal/task invocations. ### Additional Information - `__chat_id__` is only passed into the function when the parameter exists in the `pipe()` signature; this is fine. The problem is that `metadata.chat_id` is not consistently present for all invocations that come from a chat context. - For stateful/manifold functions that persist data per chat, a stable chat identifier is required to prevent state fragmentation and avoid cross-chat state mixing. - Suggested fix: ensure the backend always attaches `metadata.chat_id` for any function invocation initiated from a chat context (including internal/task routes/wrapper prompts). If some invocations are truly not chat-scoped, it would help to clearly mark them and avoid invoking chat-bound functions, or provide a stable conversation/session identifier.
GiteaMirror added the bug label 2026-04-20 01:35:10 -05:00
GiteaMirror commented 2026-04-20 01:35:12 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (Jan 11, 2026):

🔍 Similar Issues Found

I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:

  1. #20414 issue: Chats can't be archived
    by Ithanil • Jan 06, 2026 • bug

  2. #20059 issue: Chat response is not working
    by navilg • Dec 20, 2025 • bug

  3. #19127 issue: /api/v1/chats/ keeps getting called
    by HelifeWasTaken • Nov 11, 2025 • bug

  4. #19987 issue: There is a lack of visual consistency between the home page and the chat interface.
    by i-iooi-i • Dec 16, 2025 • bug

💡 Tips:

  • If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
  • If you found a solution in any of these issues, please share it here to help others

This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

<!-- gh-comment-id:3733803375 --> @owui-terminator[bot] commented on GitHub (Jan 11, 2026): 🔍 **Similar Issues Found** I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions: 1. [#20414](https://github.com/open-webui/open-webui/issues/20414) **issue: Chats can't be archived** *by Ithanil • Jan 06, 2026 • `bug`* 2. [#20059](https://github.com/open-webui/open-webui/issues/20059) **issue: Chat response is not working** *by navilg • Dec 20, 2025 • `bug`* 3. [#19127](https://github.com/open-webui/open-webui/issues/19127) **issue: /api/v1/chats/ keeps getting called** *by HelifeWasTaken • Nov 11, 2025 • `bug`* 4. [#19987](https://github.com/open-webui/open-webui/issues/19987) **issue: There is a lack of visual consistency between the home page and the chat interface.** *by i-iooi-i • Dec 16, 2025 • `bug`* --- 💡 **Tips:** - If this is a duplicate, please consider closing this issue and adding any additional details to the existing one - If you found a solution in any of these issues, please share it here to help others *This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
GiteaMirror commented 2026-04-20 01:35:12 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 11, 2026):

have a fix ready for it in a min

<!-- gh-comment-id:3734579727 --> @Classic298 commented on GitHub (Jan 11, 2026): have a fix ready for it in a min
GiteaMirror commented 2026-04-20 01:35:13 -05:00
Author
Owner
Copy Link

@moritzderallerechte commented on GitHub (Feb 6, 2026):

I am also using manifold pipes and I do not only see the metadata/chat_id missing for the internal function calls, but also for normal chat completion calls. So it never gets passed at all.
Weird how it behaves differently, even though I am on the same version (v0.7.2). But I assume this is being fixed then too.

Is there a way to get notified when a commit gets merged into a release branch?
The chat_id missing is a real issue for me

<!-- gh-comment-id:3858975101 --> @moritzderallerechte commented on GitHub (Feb 6, 2026): I am also using manifold pipes and I do not only see the metadata/chat_id missing for the internal function calls, but also for normal chat completion calls. So it never gets passed at all. Weird how it behaves differently, even though I am on the same version (v0.7.2). But I assume this is being fixed then too. Is there a way to get notified when a commit gets merged into a release branch? The chat_id missing is a real issue for me
GiteaMirror commented 2026-04-20 01:35:13 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Feb 12, 2026):

pr was merged

<!-- gh-comment-id:3893537538 --> @Classic298 commented on GitHub (Feb 12, 2026): pr was merged
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#19225
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?