From 94ceb66c170ceeee6684098cbdee0d3ba0423e55 Mon Sep 17 00:00:00 2001 From: Bryan Bartley Date: Tue, 19 May 2026 13:44:56 -0500 Subject: [PATCH] docs: clarify folder-zip cap bounds wall-clock/bandwidth not RSS Per reviewer note: because the zip streams straight into handler.wfile (no io.BytesIO buffering), peak memory is bounded by zipfile's per-file read buffer, not the HERMES_WEBUI_FOLDER_ZIP_MAX_MB cap. Adds a comment so the next reader doesn't have to trace it to learn the cap's actual shape. --- api/routes.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/api/routes.py b/api/routes.py index 18354166..40cb5535 100644 --- a/api/routes.py +++ b/api/routes.py @@ -6636,6 +6636,9 @@ def _file_raw_target(session, sid: str, rel: str) -> Path | None: # ─── /api/folder/download ─────────────────────────────────────────────────── # Configurable caps. Match the HERMES_WEBUI_MAX_UPLOAD_MB style used elsewhere # (api/config.py) so operators have one consistent env-var convention. +# Bound on per-request wall-clock and bandwidth, not RSS. The zip streams +# straight into handler.wfile, so peak memory is the per-file read buffer +# inside zipfile, not the cap value. def _folder_zip_max_bytes() -> int: try: mb = int(os.getenv("HERMES_WEBUI_FOLDER_ZIP_MAX_MB", "1024"))