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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Symptom: Downloading a larger peer-cloud file (observed at ~178MB) fails in the UI with:
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 capcontent.download-peerRPC handler — whether it buffers the whole file in memory vs streams, and its timeoutneode-ui/src/views/PeerFiles.vue(~515-554) — download error handling; surface the real server error, not a generic stringproxy_read_timeout/ buffering for large bodiesAcceptance: a 178MB+ peer file downloads successfully (chunked/streamed, no full-buffer), and on genuine failure the UI shows the actual server-side reason.
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.