bc1bb/4lbion
1
0
Fork 0
Code Issues 7 Pull requests Projects Releases Packages Wiki Activity Actions

No timeout on any requests.get() call — application hangs indefinitely on slow/unresponsive server #5

New issue
Open
opened 2026-05-14 21:10:37 +02:00 by Claude · 0 comments
Claude commented 2026-05-14 21:10:37 +02:00
Copy link

Problem

Every requests.get() call in the codebase omits a timeout parameter. The Python requests library defaults to waiting forever when no timeout is specified.

Location

4lbion.py, lines 233, 252, 279, 314, 668, 695, 734 — all requests.get(...) calls

Risk

If any upstream server (status endpoint, assets CDN, manifest server, or file download server) is slow or stops responding mid-transfer, the updater thread blocks indefinitely. Because the update thread holds the server_menu and play_button in a disabled state, the launcher becomes permanently frozen with no way for the user to recover short of killing the process. The 1.8 GB game file download at line 734 is especially vulnerable to this.

Suggested fix direction

Add a timeout=(connect_timeout, read_timeout) tuple to every requests.get() call. For the large file download a streaming approach (stream=True) with a per-chunk read timeout is preferable so that a stalled connection is detected during transfer, not only at connect time.

Severity

moderate

Found by

Automated audit by Claude Code

## Problem Every `requests.get()` call in the codebase omits a `timeout` parameter. The Python `requests` library defaults to waiting forever when no timeout is specified. ## Location `4lbion.py`, lines 233, 252, 279, 314, 668, 695, 734 — all `requests.get(...)` calls ## Risk If any upstream server (status endpoint, assets CDN, manifest server, or file download server) is slow or stops responding mid-transfer, the updater thread blocks indefinitely. Because the update thread holds the `server_menu` and `play_button` in a disabled state, the launcher becomes permanently frozen with no way for the user to recover short of killing the process. The 1.8 GB game file download at line 734 is especially vulnerable to this. ## Suggested fix direction Add a `timeout=(connect_timeout, read_timeout)` tuple to every `requests.get()` call. For the large file download a streaming approach (`stream=True`) with a per-chunk read timeout is preferable so that a stalled connection is detected during transfer, not only at connect time. ## Severity moderate ## Found by Automated audit by Claude Code
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
bc1bb/4lbion#5
No description provided.