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.