[Bug]: Long-Term Stability Issue: Ingestion Fails After Prolonged Application Use with Invalid Docling Serve URL Error

[sreedevi-m-2026]

OpenRAG Version

0.3.0

Deployment Method

uv add (installed in project)

Operating System

macOs 15.6

Python Version

3.13

Affected Area

Ingestion (document processing, upload, Docling)

Bug Description

After the application remains running for a prolonged period of continuous use (approximately 4+ hours), document ingestion starts failing. The failure occurs in the Docling Serve component with a URL protocol error, even though ingestion was working earlier in the same session.

Steps to Reproduce

1. Launch the OpenRAG application.
2. Keep the application running for an extended period, around 4 or more hours.
3. Use the application normally during this period.
4. After prolonged usage, try to ingest a document.
5. Observe the ingestion result.

Expected Behavior

The application should remain stable and responsive after prolonged continuous use, and document ingestion should continue to work normally.

Actual Behavior

Document ingestion fails after prolonged usage with the following error:

Error running graph: Error building Component Docling Serve:
Request URL is missing an 'http://' or 'https://' protocol.

Relevant Logs

Error running graph: Error building Component Docling Serve:
Request URL is missing an 'http://' or 'https://' protocol.

Screenshots

Additional Context

No response

Checklist

• I have searched existing issues to ensure this bug hasn't been reported before.
• I have provided all the requested information.

[mpawlow]

Initial Analysis

• It sounds like either Langflow or Docling has either crashed or become unresponsive
• There isn't enough information to investigate / determine the underlying issue
  • e.g. Need specific Steps To Reproduce

@sreedevi-m-2026

Follow-up Questions

• Question 1: Can you define what a "prolonged period of continuous use" involves?
  • e.g. Did you select a folder with a large number of files that took 4+ hours to ingest into knowledge?
  • Need a specific set of Steps To Reproduce and corresponding data files
• Question 2: Can you provide the logs for Backend, Langflow, and Docling when the problem occurs?
• Question 3: Can you provide us temporary access to the MacOS test server when the problem occurs ?
  • e.g. When ingestion starts to fail and the application is in a bad state
  • Assuming testing is on a shared test server rather than a laptop
• Question 4: Did any of the OpenrRAG apps crash?
  • e.g. Langflow, Backend, Docling
• Question 5: Is the problem reproducible on Linux?

[edwinjosechittilappilly]

I agree with Mike Also, can you log what file was used and the configs.

Also after how long did the error occured. @mpawlow It could also LG timed out too.

[mpawlow]

@edwinjosechittilappilly

It could also LG timed out too.

• I have definitely seen this in the past
• Where the ingestion takes too long and times out
• However, Docling is still parsing the file in the background and becomes a bottleneck for future ingestions (because the operation chain isn't fully cancelled on timeout: Backend -> Langflow -> Docling)

Another Question for QA:

• Question 6: What specific files you are ingesting?
  • e.g. https://github.com/patronus-ai/financebench# ?
  • My Linux Fyre VM would take 40+ minutes to ingest the financial documents greater than 1.5 MB in size because of the large number of embedded tables
  • The Langflow ingestion timeout occurs at 40 minutes
  • This value is configurable in your .env file
    • i.e. You can try extending the timeout to 60 minutes+ (to see if that resolves the issue for slow VMs)

# Langflow HTTP timeout configuration (in seconds)
# For large documents (300+ pages), ingestion can take 30+ minutes
# Increase these values if you experience timeouts with very large PDFs
# Default: 2400 seconds (40 minutes) total timeout, 30 seconds connection timeout
LANGFLOW_TIMEOUT=2400
# LANGFLOW_CONNECT_TIMEOUT=30

[sreedevi-m-2026]

I could able to reproduce this issue in 0.4.0 dev 8. while Bulk document ingestion via folder and details are below

Question 1: Can you define what a "prolonged period of continuous use" involves?
Ans : I could able to reproduce this issue today after 1 hour of use it self
After uploading the folder which have multiple filetypes

openrag_test_files.zip

Question 2: Can you provide the logs for Backend, Langflow, and Docling when the problem occurs?
Ans : attached all the logs

Docling log.docx
langflow.docx
openragbackendlog.docx

Question 3: Can you provide us temporary access to the MacOS test server when the problem occurs ?
e.g. When ingestion starts to fail and the application is in a bad state
Assuming testing is on a shared test server rather than a laptop
Ans: Am not sure how to provide access as am running it in my local host
Question 4: Did any of the OpenrRAG apps crash?
e.g. Langflow, Backend, Docling
in the status everything running

Question 5: Is the problem reproducible on Linux?
Ans : Reproducble in linux
Question 6: What specific files you are ingesting?
Ans : I am ingesting a folder with multiple file type . Folder has been attached

[mpawlow]

Backend Application - Key Logging Events

openrag-backend  | [2026-03-25T06:21:30.686928Z] [INFO   ] [langflow_file_service.py:188  ] [LF] Payload {'input_value': 'Ingest files', 'input_type': 'chat', 'output_type': 'text', 'tweaks': {'DoclingRemote-Dp3PX': {'path': ['1a45330f-93fa-4d52-9b8c-2bafefe37e9d/sample (3).asciidoc']}}}
openrag-backend  | [2026-03-25T06:21:31.216710Z] [ERROR  ] [langflow_file_service.py:199  ] [LF] Run failed
openrag-backend  |                                                                          - status_code: 500
openrag-backend  |                                                                          - reason: Internal Server Error
openrag-backend  |                                                                          - body: {"detail":"{\"message\":\"Error running graph: Error building Component Docling Serve: \\n\\nRequest URL is missing an 'http://' or 'https://' protocol.\",\"traceback\":null,\"description\":null,\"code\":null,\"suggestion\":\"The flow contains 4 outdated components. We recommend updating the following components: AdvancedDynamicFormBuilder-81Exw, DataFrameOperations-1BWXB, DataFrameOperations-N80fC, DataFrameOperations-9vMrp.\"}"}
openrag-backend  | [2026-03-25T06:21:31.216803Z] [ERROR  ] [langflow_file_service.py:572  ] [LF] Ingestion failed during combined operation
openrag-backend  |                                                                          - extra: {'error': "Error running graph: Error building Component Docling Serve: \n\nRequest URL is missing an 'http://' or 'https://' protocol.", 'file_path': '1a45330f-93fa-4d52-9b8c-2bafefe37e9d/sample (2).md'}
openrag-backend  | [2026-03-25T06:21:31.216873Z] [ERROR  ] [task_service.py:390           ] File processing task exception encountered
openrag-backend  |                                                                          - status: FAILED
openrag-backend  |                                                                          - task_number: 1
openrag-backend  |                                                                          - task_id: 0fb37214-bd79-44e5-aa01-fc33e6fbe5f6
openrag-backend  |                                                                          - file_path: /tmp/sample.md
openrag-backend  |                                                                          - exception: Error running graph: Error building Component Docling Serve:
openrag-backend  |
openrag-backend  | Request URL is missing an 'http://' or 'https://' protocol.
openrag-backend  | [2026-03-25T06:21:31.216955Z] [INFO   ] [task_service.py:323           ] File processing task running
openrag-backend  |                                                                          - task_number: 1
openrag-backend  |                                                                          - task_id: 0fb37214-bd79-44e5-aa01-fc33e6fbe5f6
openrag-backend  |                                                                          - file_path: /tmp/sample.

[mpawlow]

Observation 1

• Note: The test documents zip file contain file types that are not officially supported by OpenRAG for ingestion
  • i.e. ".mdx", ".xml", ".xhtml"

[mpawlow]

Observation 2

• There are 12 files in the zip file in total to ingest
• When you ingest via folder, the following status appears

• BUG: Only 9 files are ingested and the other 3 files are silently filtered out (without any error)
  • Should list 3 files as failed ingestion
• Question to investigate
  • What happened to the other 3 files?
  • e.g. Did they get sent to Docling for ingestion?

[mpawlow]

Observation from @sreedevi-m-2026

• Workaround: Once OpenRAG gets into a bad state, a restart of Docling resolves the problem

[mpawlow]

Supported Document Types in OpenRAG

  Officially Documented (docs/docs/core-components/ingestion.mdx)

  Documents:
  - .txt, .md, .html, .htm
  - .adoc, .asciidoc, .asc
  - .pdf, .docx

  Spreadsheets:
  - .csv

  The docs note that other extensions (.mdx, .xml, code/data files) are not offered in the local picker until ingestion support is confirmed. Cloud connectors may support additional types (e.g., images, older
  Office formats).

  ---
  Codebase — SUPPORTED_FILE_TYPES constant (frontend/components/knowledge-dropdown.tsx:59)

  This is the single source of truth enforced in the UI (file picker + folder ingest filter + chat drag-and-drop):

  ┌─────────────────────────────────────────────────────────────────────────┬────────────────────────┐
  │                                MIME Type                                │       Extensions       │
  ├─────────────────────────────────────────────────────────────────────────┼────────────────────────┤
  │ text/plain                                                              │ .txt                   │
  ├─────────────────────────────────────────────────────────────────────────┼────────────────────────┤
  │ text/markdown                                                           │ .md                    │
  ├─────────────────────────────────────────────────────────────────────────┼────────────────────────┤
  │ text/html                                                               │ .html, .htm            │
  ├─────────────────────────────────────────────────────────────────────────┼────────────────────────┤
  │ text/asciidoc                                                           │ .adoc, .asciidoc, .asc │
  ├─────────────────────────────────────────────────────────────────────────┼────────────────────────┤
  │ application/pdf                                                         │ .pdf                   │
  ├─────────────────────────────────────────────────────────────────────────┼────────────────────────┤
  │ application/vnd.openxmlformats-officedocument.wordprocessingml.document │ .docx                  │
  ├─────────────────────────────────────────────────────────────────────────┼────────────────────────┤
  │ text/csv                                                                │ .csv                   │
  └─────────────────────────────────────────────────────────────────────────┴────────────────────────┘

  A comment at line 56 explicitly calls out types that are pending re-verification before being re-added:
  ▎ TODO: Re-add other MIME/extension groups (images, xlsx/xls/ppt, rtf/odt, etc.) once ingestion is verified end-to-end in Langflow

  Additional notes from code

  - .txt files are internally renamed to .md before being sent to Langflow (src/models/processors.py:799), as Langflow has issues with text/plain.
  - The MIME-to-extension map in src/utils/file_utils.py:65 also includes .doc, .ppt, .pptx, .json, .xml, .rtf, and Google Docs exports — but these are not surfaced in the UI file picker.
  - Cloud connectors (Google Drive, OneDrive, SharePoint, S3, IBM COS) pass through whatever MIME type the storage service reports, so they may handle additional types that bypass the UI restriction.

[Wallgau]

It was actually a frontend issue, when user uploaded a folder containing unsupported files it will just ignore it. I fix it, should be in next release, I also fixed overwrite if duplicate file inside folder, also fix overwrite when duplicate file in folder:
https://github.com/user-attachments/assets/0989d95b-12b2-4847-8fdf-200c152de5f9