lfg2025/archy
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases 44 Wiki Activity

[Bug] Cloud download fails on larger files (e.g. 178MB) — 'Operation failed. Check server logs for details.' #38

New Issue
Closed
opened 2026-06-16 19:18:50 +00:00 by lfg2025 · 1 comment
lfg2025 commented 2026-06-16 19:18:50 +00:00
Owner
Copy Link

Symptom: Downloading a larger peer-cloud file (observed at ~178MB) fails in the UI with:

Operation failed. Check server logs for details.

Smaller files download fine; the failure appears size/duration-related.

Likely cause (to confirm): the peer-content download path lacks chunked/resumable streaming and/or hits a proxy or RPC timeout for long transfers, and the error surfaced to the UI is the generic 'Operation failed' with no detail. Related to #30 (B22 generic 'Operation failed' on peer cloud download) — this is the large-file manifestation.

Where to look:

  • core/archipelago/src/api/handler/proxy.rs (~196-259) — peer-content stream / Range handling, any total-size or timeout cap
  • the content.download-peer RPC handler — whether it buffers the whole file in memory vs streams, and its timeout
  • neode-ui/src/views/PeerFiles.vue (~515-554) — download error handling; surface the real server error, not a generic string
  • nginx peer-content proxy block — proxy_read_timeout / buffering for large bodies
  • mesh→Tor transport: large transfers over Tor may time out; needs resumable/chunked fetch with retry

Acceptance: a 178MB+ peer file downloads successfully (chunked/streamed, no full-buffer), and on genuine failure the UI shows the actual server-side reason.

**Symptom:** Downloading a larger peer-cloud file (observed at ~178MB) fails in the UI with: > Operation failed. Check server logs for details. Smaller files download fine; the failure appears size/duration-related. **Likely cause (to confirm):** the peer-content download path lacks chunked/resumable streaming and/or hits a proxy or RPC timeout for long transfers, and the error surfaced to the UI is the generic 'Operation failed' with no detail. Related to #30 (B22 generic 'Operation failed' on peer cloud download) — this is the large-file manifestation. **Where to look:** - `core/archipelago/src/api/handler/proxy.rs` (~196-259) — peer-content stream / Range handling, any total-size or timeout cap - the `content.download-peer` RPC handler — whether it buffers the whole file in memory vs streams, and its timeout - `neode-ui/src/views/PeerFiles.vue` (~515-554) — download error handling; surface the real server error, not a generic string - nginx peer-content proxy block — `proxy_read_timeout` / buffering for large bodies - mesh→Tor transport: large transfers over Tor may time out; needs resumable/chunked fetch with retry **Acceptance:** a 178MB+ peer file downloads successfully (chunked/streamed, no full-buffer), and on genuine failure the UI shows the actual server-side reason.
lfg2025 commented 2026-06-17 08:15:30 +00:00
Author
Owner
Copy Link

Fixed in commit e456c970 (together with #30). Large downloads (~178MB) failed because: the free path pulled the whole file as base64 over RPC (doubling it in node memory + the browser), the peer-content proxy buffered the entire file via resp.bytes(), and timeouts were too tight. Now: free downloads stream straight to disk from /api/peer-content (constant memory), the proxy uses hyper wrap_stream (no buffering) with a 900s timeout, nginx peer-content read timeout raised to 900s, and the FIPS client honors the per-request timeout. Pending live deploy verification on a large file.

Fixed in commit e456c970 (together with #30). Large downloads (~178MB) failed because: the free path pulled the whole file as base64 over RPC (doubling it in node memory + the browser), the peer-content proxy buffered the entire file via resp.bytes(), and timeouts were too tight. Now: free downloads stream straight to disk from /api/peer-content (constant memory), the proxy uses hyper wrap_stream (no buffering) with a 900s timeout, nginx peer-content read timeout raised to 900s, and the FIPS client honors the per-request timeout. Pending live deploy verification on a large file.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
lfg2025
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lfg2025/archy#38
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?