Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
omarchy-network-speedtest reports erratic near-zero speeds due to missing curl timeout on flaky OCA endpoint
Reported by BundyFarino · filed Sep 8, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
What happened
Running omarchy network speedtest down (and up) reports wildly erratic, mostly near-zero throughput (a handful of high readings like 891/934/375 Mbps followed by long runs of 0.0), even though the actual link is fast.
Root cause
omarchy-network-speedtest fetches 3 candidate OCA server URLs from the fast.com API and spins up 8 parallel curl workers that round-robin across them in a loop for the duration of the test. None of the curl invocations set --connect-timeout or --max-time.
On my network, one of the 3 returned OCA endpoints (an ipv6-* host) is intermittently very slow/hangs (confirmed via repeated manual curl tests — sometimes completes in <0.5s, sometimes hangs past an 8s timeout with no response). Because the script has no timeout, any worker whose round-robin cycle lands on that endpoint at a bad moment just hangs forever — traffic_worker never returns and never retries a different URL, so that worker permanently stops contributing to the measured rate. As more of the 8 workers get stuck this way, total measured throughput collapses toward 0, producing the erratic/near-zero pattern.
Confirmed the real link speed is not the problem: manual single-shot curl downloads (no parallelism) against the same OCA servers repeatedly completed a 25MB payload in ~0.3-0.5s (~500-700 Mbps).
Expected
The test should not silently collapse to near-zero when one of the 3 provided endpoints is flaky. At minimum, each curl call in traffic_worker should set a reasonable --connect-timeout/--max-time, and a worker should pick a new random URL / continue looping rather than permanently dying (return) after a single failure.
Steps to reproduce
- Run
omarchy network speedtest downon a network where one of the 3fast.com-provided OCA endpoints is intermittently slow/unreachable. - Observe long streaks of
0.0interspersed with occasional legitimate-looking bursts.
System details
- Omarchy version: 4.0.2-1
uname -a: $(uname -a)- Script:
/usr/share/omarchy/bin/omarchy-network-speedtest
View raw text
## What happened Running `omarchy network speedtest down` (and `up`) reports wildly erratic, mostly near-zero throughput (a handful of high readings like 891/934/375 Mbps followed by long runs of `0.0`), even though the actual link is fast. ## Root cause `omarchy-network-speedtest` fetches 3 candidate OCA server URLs from the `fast.com` API and spins up 8 parallel `curl` workers that round-robin across them in a loop for the duration of the test. None of the `curl` invocations set `--connect-timeout` or `--max-time`. On my network, one of the 3 returned OCA endpoints (an `ipv6-*` host) is intermittently very slow/hangs (confirmed via repeated manual `curl` tests — sometimes completes in <0.5s, sometimes hangs past an 8s timeout with no response). Because the script has no timeout, any worker whose round-robin cycle lands on that endpoint at a bad moment just hangs forever — `traffic_worker` never returns and never retries a different URL, so that worker permanently stops contributing to the measured rate. As more of the 8 workers get stuck this way, total measured throughput collapses toward 0, producing the erratic/near-zero pattern. Confirmed the real link speed is not the problem: manual single-shot `curl` downloads (no parallelism) against the same OCA servers repeatedly completed a 25MB payload in ~0.3-0.5s (~500-700 Mbps). ## Expected The test should not silently collapse to near-zero when one of the 3 provided endpoints is flaky. At minimum, each `curl` call in `traffic_worker` should set a reasonable `--connect-timeout`/`--max-time`, and a worker should pick a new random URL / continue looping rather than permanently dying (`return`) after a single failure. ## Steps to reproduce 1. Run `omarchy network speedtest down` on a network where one of the 3 `fast.com`-provided OCA endpoints is intermittently slow/unreachable. 2. Observe long streaks of `0.0` interspersed with occasional legitimate-looking bursts. ## System details - Omarchy version: 4.0.2-1 - `uname -a`: $(uname -a) - Script: `/usr/share/omarchy/bin/omarchy-network-speedtest`
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 11:08 UTC