[Bug]: Infinite block and thread pool starvation in OneDriveReader due to missing timeout in requests.get()

[QiuYucheng2003]

Bug Description

The OneDriveReader component makes synchronous HTTP calls using requests.get() without specifying a timeout parameter. According to the requests documentation, lacking a timeout means the client will block indefinitely if the server does not send a response after the TCP handshake.

In production RAG pipelines, if the Microsoft Graph API experiences network blackholes, temporary outages, or severe rate-limiting, these operations will hang forever. Due to Python's GIL and thread pool limits, multiple concurrent hung requests will quickly exhaust all available worker threads, leading to a complete Denial of Service (DoS) of the host application or agent container.

Affected methods in llama_index/readers/microsoft_onedrive/base.py:

_download_file_by_url

_get_items_in_drive_with_maxretries

_get_permissions_info

Suggested Fix:
Enforce a reasonable timeout tuple (e.g., timeout=(3.0, 30.0)) on all requests.get() calls within this module.

Version

main

Steps to Reproduce

This is an underlying network logic flaw. To conceptually reproduce:

1. Initialize OneDriveReader and execute load_data().

2. Simulate a network hang (e.g., using iptables to drop packets from graph.microsoft.com after the initial connection, or mock requests.get to sleep indefinitely).

3. Observe that the application execution hangs forever without raising any Timeout exceptions.

4. If running in a threaded environment, observe that the thread pool becomes completely starved and unresponsive.

Relevant Logs/Tracebacks

# No explicit traceback is generated because the process hangs indefinitely.
# The application thread remains permanently stuck in the socket read phase, awaiting a response that never arrives.

[dosubot]

You're correct — all three methods (_download_file_by_url, _get_items_in_drive_with_maxretries, and _get_permissions_info) make requests.get() calls without a timeout parameter [1].

There's good news: PR #22029 ("fix: add missing timeout to HTTP requests across 9 integration packages") is currently open and addresses this systematic issue. Additionally, PR #21969 tackles a related problem — blocking HTTP and file I/O in the async methods of OneDriveReader by offloading synchronous work via asyncio.to_thread().

It's worth noting that _get_items_in_drive_with_maxretries does implement retry logic for 429/5xx status codes [2], but as you point out, that doesn't help when the request itself never completes at the socket level.

Your suggested fix of timeout=(3.0, 30.0) (connect timeout, read timeout) is a reasonable default. You may want to check whether PR #22029 already covers OneDrive specifically, and if not, consider contributing that fix or coordinating with that PR's author.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.