> **Edit history:** this issue was originally filed claiming a Cloudflare caching misconfiguration. **That diagnosis was wrong and has been removed from this body** — package artifacts are correctly edge-cached. See [the correction comment](https://github.com/omacom/omarchy/issues/11793#issuecomment-5663618800) for what I got wrong and why. The body below is the narrowed, still-valid issue.

## Summary

A transient mid-download stall fails an entire `omarchy-update` transaction, because pacman's low-speed abort threshold is 1 byte over 10 seconds. Stalls appear to be recoverable within ~20-30 seconds, but pacman has already given up by then, and the resulting message reads like a server outage.

## Symptom

```
:: Retrieving packages...
 mise-bin-2026.9.5-1-x86_64.pkg.tar.zst failed to download
error: failed retrieving file 'mise-bin-2026.9.5-1-x86_64.pkg.tar.zst' from pkgs.omarchy.org : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds
error: failed to commit transaction (failed to retrieve some files)

Something went wrong during the update!
```

Recurring rather than one-off, across multiple updates on this machine.

## The stall, measured

Fetching the same 35 MB package directly, the transfer froze for ~23 seconds at 19.42 MB and then recovered on its own:

```
55 34.99M  55 19.42M    0     0  3.25M      0  00:05
55 34.99M  55 19.42M    0     0  1.02M      0  00:19    # 0 B/s
55 34.99M  55 19.42M    0     0  710k       0  00:28    # still 0 B/s
100 34.99M 100 34.99M   0     0  1.00M      0  00:34    # recovered, exit 0
```

pacman would have aborted at roughly 00:15.

## Scope — what this is NOT

The CDN is fine. Ranged GETs (the request type pacman issues) are served from cache:

```
cf-cache-status: HIT    age: 17475
cf-cache-status: HIT    age: 17476
cf-cache-status: HIT    age: 17477
```

So the stall occurs on a cache hit, somewhere between edge and client. **It may well be specific to my network path — I egress through a VPN — and not something Omarchy controls.** I am not claiming a server-side defect.

## What I think is worth considering

Regardless of the stall's origin, the failure mode is harsher than it needs to be: one hiccup on one file aborts the whole transaction, and the error blames the server. A more forgiving transfer config absorbs it. This works on my machine:

```
XferCommand = /usr/bin/curl --fail --location --continue-at - --retry 5 --retry-delay 3 --connect-timeout 15 --speed-limit 2048 --speed-time 60 -o %o %u
```

- `--speed-limit 2048 --speed-time 60` replaces the 1-byte/10s floor with 2 KB/s over 60s
- `--continue-at -` resumes a partial file rather than restarting it

**Evidence provenance.** With this in place, the 23-second stall above completed instead of aborting. That run finished in a single attempt (exit 0, 34.96s, no retry lines emitted), so the recovery came from `--speed-time 60` raising the abort threshold, not from any retry flag — which means the result holds for the line exactly as written above. Separately verified: the 404 path, 26s -> 0s after removing `--retry-all-errors`.

**Real caveat:** setting `XferCommand` disables `ParallelDownloads`, trading update speed for resilience. That may not be a trade Omarchy wants to make by default, which is why this is a discussion point rather than a proposed patch. A narrower alternative would be documenting it as a remedy for users who hit this repeatedly.

Entirely reasonable to close this if the stall is judged to be local to my connection.

## Environment

- Omarchy on Arch, `x86_64`
- pacman with `ParallelDownloads = 5`, `DownloadUser = alpm`
- Failing package: `omarchy/mise-bin` `2026.9.4-1` -> `2026.9.5-1`
- Cloudflare edge: MAD; client egresses via VPN

---

## Update: the mitigation above originally contained a defect (now corrected)

The `XferCommand` I first posted included `--retry-all-errors`. **Do not use that flag here.** It makes curl retry definitive HTTP 404s, and pacman routinely probes for optional files that legitimately 404, so every one of those probes becomes 8 retries with 3-second delays. On my machine it turned `omarchy-update` into a crawl of repeated `curl: (22) ... 404 / Retrying in 3 seconds. 8 retries left`, which is considerably worse than the intermittent stall I was trying to fix. I reverted to a stock `pacman.conf` and updates work normally again.

Measured, same nonexistent URL, both forms:

```
with --retry-all-errors : 26s   (8 retries against a 404)
plain --retry           :  0s   (fails immediately, correctly)
```

The line in the body above now uses plain `--retry`, which only retries transient failures. **Caveat: I have verified it handles a 404 correctly, but I have not re-run a full `omarchy-update` cycle with it in place**, so please treat it as a discussion point rather than something to ship on my say-so.