SyntaxError: Unexpected token 'd', "data: {"id"... is not valid JSON #3697

New Issue

Closed

opened 2025-11-11 15:37:17 -06:00 by GiteaMirror · 19 comments

GiteaMirror commented 2025-11-11 15:37:17 -06:00

Owner

Copy Link

Originally created by @Thinker-Joe on GitHub (Feb 8, 2025).

Bug Report

Installation Method

Docker

Environment

• Open WebUI Version: v0.5.10
• Ollama (if applicable): N/A
• Operating System: Windows 10
• Browser (if applicable): Chrome 132

Confirmation:

• I have read and followed all the instructions provided in the README.md.
• I am on 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 the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

Expected Behavior:

The API should return a valid JSON response without causing a syntax error.

Actual Behavior:

A SyntaxError occurs in the browser console when processing the response. The error message is:

SyntaxError: Unexpected token 'd', "data: {"id"..." is not valid JSON

The response appears to contain improperly formatted JSON data.

Description

Bug Summary:
When making a request to the completions API endpoint, the response data is not in valid JSON format. This causes the application to throw a SyntaxError.

Reproduction Details

Steps to Reproduce:

1. Install Open WebUI using Docker.
2. Access the web interface via Chrome.
3. Trigger a request to the completions endpoint.
4. Open the browser's developer tools, go to the Network tab, and observe the response for the completions API call.
5. Note the error in the Console tab.

Logs and Screenshots

Browser Console Logs:

SyntaxError: Unexpected token 'd', "data: {"id"..." is not valid JSON

Docker Container Logs:

INFO  [open_webui.routers.openai] get_all_models()
INFO:     58.250.179.242:0 - "POST /api/v1/chats/new HTTP/1.1" 200 OK
INFO:     58.250.179.242:0 - "GET /static/favicon.png HTTP/1.1" 304 Not Modified
INFO:     58.250.179.242:0 - "GET /api/v1/chats/?page=2 HTTP/1.1" 200 OK
INFO:     58.250.179.242:0 - "GET /static/favicon.png HTTP/1.1" 304 Not Modified
INFO:     58.250.179.242:0 - "POST /api/v1/chats/06ae7404-3916-400b-90d6-b0ef49d233dc HTTP/1.1" 200 OK
INFO:     58.250.179.242:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK
INFO  [open_webui.routers.openai] get_all_models()
INFO:     58.250.179.242:0 - "POST /api/v1/tasks/auto/completions HTTP/1.1" 200 OK
INFO:     58.250.179.242:0 - "GET /ws/socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 Bad Request
INFO:     58.250.179.242:0 - "POST /api/chat/completions HTTP/1.1" 200 OK
INFO:     58.250.179.242:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK
INFO:     58.250.179.242:0 - "GET /ws/socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 Bad Request
INFO:     58.250.179.242:0 - "GET /ws/socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 Bad Request

Screenshots/Screen Recordings (if applicable):
[Attached screenshot for reference.]

Additional Information

The issue seems related to how the EventStream API responses are being handled. Specifically, the data: {} format is not parsed correctly as JSON.

Note

If further logs or testing are needed, I am happy to assist. Please let me know if additional details are required.

Originally created by @Thinker-Joe on GitHub (Feb 8, 2025). # Bug Report ## Installation Method Docker ## Environment - **Open WebUI Version:** v0.5.10 - **Ollama (if applicable):** N/A - **Operating System:** Windows 10 - **Browser (if applicable):** Chrome 132 **Confirmation:** - [x] I have read and followed all the instructions provided in the README.md. - [x] I am on 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 the exact steps to reproduce the bug in the "Steps to Reproduce" section below. ## Expected Behavior: The API should return a valid JSON response without causing a syntax error. ## Actual Behavior: A `SyntaxError` occurs in the browser console when processing the response. The error message is: ``` SyntaxError: Unexpected token 'd', "data: {"id"..." is not valid JSON ``` The response appears to contain improperly formatted JSON data. ## Description **Bug Summary:** When making a request to the `completions` API endpoint, the response data is not in valid JSON format. This causes the application to throw a `SyntaxError`. ## Reproduction Details **Steps to Reproduce:** 1. Install Open WebUI using Docker. 2. Access the web interface via Chrome. 3. Trigger a request to the `completions` endpoint. 4. Open the browser's developer tools, go to the Network tab, and observe the response for the `completions` API call. 5. Note the error in the Console tab. ## Logs and Screenshots **Browser Console Logs:** ``` SyntaxError: Unexpected token 'd', "data: {"id"..." is not valid JSON ```   **Docker Container Logs:** ``` INFO [open_webui.routers.openai] get_all_models() INFO: 58.250.179.242:0 - "POST /api/v1/chats/new HTTP/1.1" 200 OK INFO: 58.250.179.242:0 - "GET /static/favicon.png HTTP/1.1" 304 Not Modified INFO: 58.250.179.242:0 - "GET /api/v1/chats/?page=2 HTTP/1.1" 200 OK INFO: 58.250.179.242:0 - "GET /static/favicon.png HTTP/1.1" 304 Not Modified INFO: 58.250.179.242:0 - "POST /api/v1/chats/06ae7404-3916-400b-90d6-b0ef49d233dc HTTP/1.1" 200 OK INFO: 58.250.179.242:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK INFO [open_webui.routers.openai] get_all_models() INFO: 58.250.179.242:0 - "POST /api/v1/tasks/auto/completions HTTP/1.1" 200 OK INFO: 58.250.179.242:0 - "GET /ws/socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 Bad Request INFO: 58.250.179.242:0 - "POST /api/chat/completions HTTP/1.1" 200 OK INFO: 58.250.179.242:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK INFO: 58.250.179.242:0 - "GET /ws/socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 Bad Request INFO: 58.250.179.242:0 - "GET /ws/socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 Bad Request ``` **Screenshots/Screen Recordings (if applicable):** [Attached screenshot for reference.] ## Additional Information The issue seems related to how the EventStream API responses are being handled. Specifically, the `data: {}` format is not parsed correctly as JSON. ## Note If further logs or testing are needed, I am happy to assist. Please let me know if additional details are required.

GiteaMirror closed this issue 2025-11-11 15:37:18 -06:00

GiteaMirror commented 2025-11-11 15:37:19 -06:00

Author

Owner

Copy Link

@Thinker-Joe commented on GitHub (Feb 8, 2025):

The issue has been solved, websocket support needs to be enabled

@Thinker-Joe commented on GitHub (Feb 8, 2025): The issue has been solved, websocket support needs to be enabled 

GiteaMirror commented 2025-11-11 15:37:19 -06:00

Author

Owner

Copy Link

@FlechazoPh commented on GitHub (Feb 10, 2025):

The issue has been solved, websocket support needs to be enabled问题已解决，需要启用WebSocket支持

Where is the websocket support setting ? chrome client or my server?

@FlechazoPh commented on GitHub (Feb 10, 2025): > The issue has been solved, websocket support needs to be enabled问题已解决，需要启用WebSocket支持 > >  Where is the websocket support setting ? chrome client or my server?

GiteaMirror commented 2025-11-11 15:37:19 -06:00

Author

Owner

Copy Link

@enterusernamecontinue commented on GitHub (Feb 10, 2025):

The issue has been solved, websocket support needs to be enabled问题已解决，需要启用WebSocket支持

Where is the websocket support setting ? chrome client or my server?

创建反向代理时，启用 WebSocket 支持。

@enterusernamecontinue commented on GitHub (Feb 10, 2025): > > The issue has been solved, websocket support needs to be enabled问题已解决，需要启用WebSocket支持 > >  > > Where is the websocket support setting ? chrome client or my server? 创建反向代理时，启用 WebSocket 支持。

GiteaMirror commented 2025-11-11 15:37:20 -06:00

Author

Owner

Copy Link

@micjac99 commented on GitHub (Feb 10, 2025):

the same issue . perfectly solved!!!!!!

@micjac99 commented on GitHub (Feb 10, 2025): the same issue . perfectly solved!!!!!!

GiteaMirror commented 2025-11-11 15:37:20 -06:00

Author

Owner

Copy Link

@FlechazoPh commented on GitHub (Feb 11, 2025):

The issue has been solved, websocket support needs to be enabled问题已解决，需要启用WebSocket支持

Where is the websocket support setting ? chrome client or my server?

创建反向代理时，启用 WebSocket 支持。

Solved, thanks~

@FlechazoPh commented on GitHub (Feb 11, 2025): > > > The issue has been solved, websocket support needs to be enabled问题已解决，需要启用WebSocket支持 > > >  > > > > > > Where is the websocket support setting ? chrome client or my server? > > 创建反向代理时，启用 WebSocket 支持。 Solved, thanks~

GiteaMirror commented 2025-11-11 15:37:20 -06:00

Author

Owner

Copy Link

@caoshiny commented on GitHub (Feb 13, 2025):

The issue has been solved, websocket support needs to be enabled问题已解决，需要启用WebSocket支持

Where is the websocket support setting ? chrome client or my server?

创建反向代理时，启用 WebSocket 支持。

Solved, thanks~
where is the setting? plz tell me, thanks

@caoshiny commented on GitHub (Feb 13, 2025): > > > > The issue has been solved, websocket support needs to be enabled问题已解决，需要启用WebSocket支持 > > > >  > > > > > > > > > Where is the websocket support setting ? chrome client or my server? > > > > > > 创建反向代理时，启用 WebSocket 支持。 > > Solved, thanks~ where is the setting? plz tell me, thanks

GiteaMirror commented 2025-11-11 15:37:21 -06:00

Author

Owner

Copy Link

@CVYang commented on GitHub (Feb 13, 2025):

in company, websocket is banned by waf. any other method to solve this problem? does websocket used by openwebui or ollama???

@CVYang commented on GitHub (Feb 13, 2025): in company, websocket is banned by waf. any other method to solve this problem? does websocket used by openwebui or ollama???

GiteaMirror commented 2025-11-11 15:37:21 -06:00

Author

Owner

Copy Link

@JokerQyou commented on GitHub (Feb 19, 2025):

However, if websocket connection is not established (e.g. WS connection blocked by WAF or load balancer), the API request to /api/chat/completions is still an SSE request, and it outputs event stream, can't the frontend just continue to use this stream like it did before? Right now it seems to drop this source. The syntax error is likely that SSE events are not correctly parsed: each stream has a data: prefix (according to SSE standard), so SSE events need an additional stripping compared to WS events.

@JokerQyou commented on GitHub (Feb 19, 2025): However, if websocket connection is not established (e.g. WS connection blocked by WAF or load balancer), the API request to `/api/chat/completions` is still an SSE request, and it outputs event stream, can't the frontend just continue to use this stream like it did before? Right now it seems to drop this source. The syntax error is likely that SSE events are not correctly parsed: each stream has a `data: ` prefix (according to SSE standard), so SSE events need an additional stripping compared to WS events.

GiteaMirror commented 2025-11-11 15:37:22 -06:00

Author

Owner

Copy Link

@overnightover commented on GitHub (Feb 20, 2025):

The issue has been solved, websocket support needs to be enabled

这个设置界面在哪plz

@overnightover commented on GitHub (Feb 20, 2025): > The issue has been solved, websocket support needs to be enabled > >  这个设置界面在哪plz

GiteaMirror commented 2025-11-11 15:37:22 -06:00

Author

Owner

Copy Link

@overnightover commented on GitHub (Feb 20, 2025):

The issue has been solved, websocket support needs to be enabled

这个设置界面在哪plz

打扰了，在反向代理中找到设置了

@overnightover commented on GitHub (Feb 20, 2025): > > The issue has been solved, websocket support needs to be enabled > >  > > 这个设置界面在哪plz 打扰了，在反向代理中找到设置了

GiteaMirror commented 2025-11-11 15:37:23 -06:00

Author

Owner

Copy Link

@yuboqi commented on GitHub (Feb 21, 2025):

However, if websocket connection is not established (e.g. WS connection blocked by WAF or load balancer), the API request to /api/chat/completions is still an SSE request, and it outputs event stream, can't the frontend just continue to use this stream like it did before? Right now it seems to drop this source. The syntax error is likely that SSE events are not correctly parsed: each stream has a data: prefix (according to SSE standard), so SSE events need an additional stripping compared to WS events.但是，如果未建立 websocket 连接（例如，WS 连接被 WAF 或负载均衡器阻止），则对 /api/chat/completions 的 API 请求仍然是 SSE 请求，并且它输出事件流，前端不能像以前一样继续使用此流吗？现在它似乎放弃了这个来源。语法错误可能是 SSE 事件没有被正确解析：每个流都有一个 data： 前缀（根据 SSE 标准），因此与 WS 事件相比，SSE 事件需要额外的剥离。

Has this problem been solved?

@yuboqi commented on GitHub (Feb 21, 2025): > However, if websocket connection is not established (e.g. WS connection blocked by WAF or load balancer), the API request to `/api/chat/completions` is still an SSE request, and it outputs event stream, can't the frontend just continue to use this stream like it did before? Right now it seems to drop this source. The syntax error is likely that SSE events are not correctly parsed: each stream has a `data: ` prefix (according to SSE standard), so SSE events need an additional stripping compared to WS events.但是，如果未建立 websocket 连接（例如，WS 连接被 WAF 或负载均衡器阻止），则对 `/api/chat/completions` 的 API 请求仍然是 SSE 请求，并且它输出事件流，前端不能像以前一样继续使用此流吗？现在它似乎放弃了这个来源。语法错误可能是 SSE 事件没有被正确解析：每个流都有一个 `data： ` 前缀（根据 SSE 标准），因此与 WS 事件相比，SSE 事件需要额外的剥离。 Has this problem been solved?

GiteaMirror commented 2025-11-11 15:37:23 -06:00

Author

Owner

Copy Link

@JokerQyou commented on GitHub (Feb 21, 2025):

I don't think so. Correctly reverse-proxying websocket connections and you won't hit this issue. If you happen to use Cloudflare Tunnels (cloudflared with ZeroTrust dashboard config) then this issue would persist.

@JokerQyou commented on GitHub (Feb 21, 2025): I don't think so. Correctly reverse-proxying websocket connections and you won't hit this issue. If you happen to use Cloudflare Tunnels (`cloudflared` with ZeroTrust dashboard config) then this issue would persist.

GiteaMirror commented 2025-11-11 15:37:23 -06:00

Author

Owner

Copy Link

@voznik commented on GitHub (Feb 23, 2025):

I have this issue without any proxy, on local Linux machine, running openwebui with docker & local ollama service, with --host mode and with "Manage Ollama API Connections" setting set to http://127.0.0.1:11434
I don't understand how "proxy" answer could be applicable

@voznik commented on GitHub (Feb 23, 2025): I have this issue without any proxy, on local Linux machine, running openwebui with docker & local ollama service, with --host mode and with "Manage Ollama API Connections" setting set to http://127.0.0.1:11434 I don't understand how "proxy" answer could be applicable

GiteaMirror commented 2025-11-11 15:37:24 -06:00

Author

Owner

Copy Link

@Thinker-Joe commented on GitHub (Feb 24, 2025):

I don't think so. Correctly reverse-proxying websocket connections and you won't hit this issue. If you happen to use Cloudflare Tunnels (cloudflared with ZeroTrust dashboard config) then this issue would persist.

However, it should be noted that:

1. This is a breaking update (not backward compatible) that only affects the most recent versions
2. The official documentation currently does not explicitly state that WebSocket support is required for application deployment (this is also not mentioned in recent version release notes)

These are extremely poor practices that significantly undermine Open WebUI's usability and brand value.

@Thinker-Joe commented on GitHub (Feb 24, 2025): > I don't think so. Correctly reverse-proxying websocket connections and you won't hit this issue. If you happen to use Cloudflare Tunnels (`cloudflared` with ZeroTrust dashboard config) then this issue would persist. However, it should be noted that: 1. This is a breaking update (not backward compatible) that only affects the most recent versions 2. The official documentation currently does not explicitly state that WebSocket support is required for application deployment (this is also not mentioned in recent version release notes) These are extremely poor practices that significantly undermine Open WebUI's usability and brand value.

GiteaMirror commented 2025-11-11 15:37:24 -06:00

Author

Owner

Copy Link

@JokerQyou commented on GitHub (Feb 24, 2025):

I don't think so. Correctly reverse-proxying websocket connections and you won't hit this issue. If you happen to use Cloudflare Tunnels (cloudflared with ZeroTrust dashboard config) then this issue would persist.

However, it should be noted that:

1. This is a breaking update (not backward compatible) that only affects the most recent versions
2. The official documentation currently does not explicitly state that WebSocket support is required for application deployment (this is also not mentioned in recent version release notes)

These are extremely poor practices that significantly undermine Open WebUI's usability and brand value.

I know. It's not documented anywhere but in changelog of v0.5.0:

⚙️ Backend Overhaul for Performance: Major backend restructuring; a heads-up that some "Functions" using internal variables may face compatibility issues. Moving forward, websocket support is mandatory to ensure Open WebUI operates seamlessly.

I'm not a developer of OpenWebUI. And as I pointed out in an earlier comment, OpenWebUI should continue to support SSE alongside websocket.

@JokerQyou commented on GitHub (Feb 24, 2025): > > I don't think so. Correctly reverse-proxying websocket connections and you won't hit this issue. If you happen to use Cloudflare Tunnels (`cloudflared` with ZeroTrust dashboard config) then this issue would persist. > > However, it should be noted that: > > 1. This is a breaking update (not backward compatible) that only affects the most recent versions > 2. The official documentation currently does not explicitly state that WebSocket support is required for application deployment (this is also not mentioned in recent version release notes) > > These are extremely poor practices that significantly undermine Open WebUI's usability and brand value. I know. It's not documented anywhere but in [changelog of v0.5.0](https://github.com/open-webui/open-webui/releases/tag/v0.5.0): > ⚙️ Backend Overhaul for Performance: Major backend restructuring; a heads-up that some "Functions" using internal variables may face compatibility issues. **Moving forward, websocket support is mandatory to ensure Open WebUI operates seamlessly.** I'm not a developer of OpenWebUI. And as I pointed out in an earlier comment, OpenWebUI should continue to support SSE alongside websocket.

GiteaMirror commented 2025-11-11 15:37:24 -06:00

Author

Owner

Copy Link

@Thinker-Joe commented on GitHub (Feb 24, 2025):

I have this issue without any proxy, on local Linux machine, running openwebui with docker & local ollama service, with --host mode and with "Manage Ollama API Connections" setting set to http://127.0.0.1:11434 I don't understand how "proxy" answer could be applicable

The problem occurs in the connection between your browser and the Open WebUI backend server. You need to check all network nodes in your path to accessing Open WebUI, rather than the Ollama API (which is unrelated to this problem).

The core point is that Open WebUI's API Server now requires WebSocket support. If you have any reverse proxies, load balancers, WAF (Web Application Firewall), or similar services in front of your Open WebUI service, you need to verify that they support WebSocket and have WebSocket support enabled.

@Thinker-Joe commented on GitHub (Feb 24, 2025): > I have this issue without any proxy, on local Linux machine, running openwebui with docker & local ollama service, with --host mode and with "Manage Ollama API Connections" setting set to http://127.0.0.1:11434 I don't understand how "proxy" answer could be applicable The problem occurs in the connection between your browser and the Open WebUI backend server. You need to check all network nodes in your path to accessing Open WebUI, rather than the Ollama API (which is unrelated to this problem). The core point is that Open WebUI's API Server now requires WebSocket support. If you have any reverse proxies, load balancers, WAF (Web Application Firewall), or similar services in front of your Open WebUI service, you need to verify that they support WebSocket and have WebSocket support enabled.

GiteaMirror commented 2025-11-11 15:37:25 -06:00

Author

Owner

Copy Link

@Thinker-Joe commented on GitHub (Feb 24, 2025):

I don't think so. Correctly reverse-proxying websocket connections and you won't hit this issue. If you happen to use Cloudflare Tunnels (cloudflared with ZeroTrust dashboard config) then this issue would persist.

However, it should be noted that:

1. This is a breaking update (not backward compatible) that only affects the most recent versions
2. The official documentation currently does not explicitly state that WebSocket support is required for application deployment (this is also not mentioned in recent version release notes)

These are extremely poor practices that significantly undermine Open WebUI's usability and brand value.

I know. It's not documented anywhere but in changelog of v0.5.0:

⚙️ Backend Overhaul for Performance: Major backend restructuring; a heads-up that some "Functions" using internal variables may face compatibility issues. Moving forward, websocket support is mandatory to ensure Open WebUI operates seamlessly.

I'm not a developer of OpenWebUI. And as I pointed out in an earlier comment, OpenWebUI should continue to support SSE alongside websocket.

Yep, many thanks you for your research, just hope our discussion can attract the attention of developers.

@Thinker-Joe commented on GitHub (Feb 24, 2025): > > > I don't think so. Correctly reverse-proxying websocket connections and you won't hit this issue. If you happen to use Cloudflare Tunnels (`cloudflared` with ZeroTrust dashboard config) then this issue would persist. > > > > > > However, it should be noted that: > > > > 1. This is a breaking update (not backward compatible) that only affects the most recent versions > > 2. The official documentation currently does not explicitly state that WebSocket support is required for application deployment (this is also not mentioned in recent version release notes) > > > > These are extremely poor practices that significantly undermine Open WebUI's usability and brand value. > > I know. It's not documented anywhere but in [changelog of v0.5.0](https://github.com/open-webui/open-webui/releases/tag/v0.5.0): > > > ⚙️ Backend Overhaul for Performance: Major backend restructuring; a heads-up that some "Functions" using internal variables may face compatibility issues. **Moving forward, websocket support is mandatory to ensure Open WebUI operates seamlessly.** > > I'm not a developer of OpenWebUI. And as I pointed out in an earlier comment, OpenWebUI should continue to support SSE alongside websocket. Yep, many thanks you for your research, just hope our discussion can attract the attention of developers.

GiteaMirror commented 2025-11-11 15:37:25 -06:00

Author

Owner

Copy Link

@sumitchatterjee13 commented on GitHub (Apr 6, 2025):

I am getting same error just after updating today. I don't know much about WebSocket and how to fix this issue.

@sumitchatterjee13 commented on GitHub (Apr 6, 2025): I am getting same error just after updating today. I don't know much about WebSocket and how to fix this issue.

GiteaMirror commented 2025-11-11 15:37:25 -06:00

Author

Owner

Copy Link

@sunshibao commented on GitHub (Apr 18, 2025):

在Nginx 配置里添加
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

@sunshibao commented on GitHub (Apr 18, 2025): 在Nginx 配置里添加 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

GiteaMirror referenced this issue 2026-04-19 20:07:15 -05:00

[GH-ISSUE #3697] WebUI models not being pulled/applied from site #13353

GiteaMirror referenced this issue 2026-04-25 03:24:46 -05:00

[GH-ISSUE #3697] WebUI models not being pulled/applied from site #28881

GiteaMirror referenced this issue 2026-05-05 13:14:37 -05:00

[GH-ISSUE #3697] WebUI models not being pulled/applied from site #52019

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

v0.9.5

v0.9.4

v0.9.3

v0.9.2

v0.9.1

v0.9.0

v0.8.12

v0.8.11

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

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

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#3697