From acd03b147c9ab18a75864e07f89f08b188eb072d Mon Sep 17 00:00:00 2001
From: Classic298 <27028174+Classic298@users.noreply.github.com>
Date: Sat, 5 Sep 2026 01:13:04 +0200
Subject: [PATCH] fix: treat .ino files as source text so knowledge uploads
 stop failing (#29673)

Uploading an Arduino sketch (`.ino`) to a knowledge base failed with `Expecting value: line 1 column 1 (char 0)` whenever the content extraction engine was Tika or Docling. Browsers send `.ino` as `application/octet-stream`, and the extension was missing from the known source extension list, so the file was handed to the extraction server instead of being read as plain text. The server answered with a non-JSON body and the loader crashed while decoding it. `.cpp` and `.h` sketches in the same folder uploaded fine, because those extensions are already on the list.

Adding `ino` to that list routes it to the plain text loader, the same way the yaml/toml gap was closed in 710320601a3b15dc65acc3944c81455257be46ac. A sketch is plain C++ text, so there is nothing for a document extraction server to do with it.

Verified by dispatch matrix over 35 extensions, 5 content types and all 8 engines against a stub server that reproduces the non-JSON response: the only rows that change are `.ino` under Tika and Docling, which now resolve to the text loader and extract the sketch verbatim. Every other row is unchanged.

Fixes #29670
---
 backend/open_webui/retrieval/loaders/main.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/backend/open_webui/retrieval/loaders/main.py b/backend/open_webui/retrieval/loaders/main.py
index f84b2a2b1b..13570c37f0 100644
--- a/backend/open_webui/retrieval/loaders/main.py
+++ b/backend/open_webui/retrieval/loaders/main.py
@@ -50,6 +50,7 @@ known_source_ext = [
     'h',
     'c',
     'cs',
+    'ino',
     'sql',
     'log',
     'ini',