From 2a16b3f962fc40d43ee1a73831aca99284fd3ce1 Mon Sep 17 00:00:00 2001
From: Nick Szaunig <nick.szaunig@encry.de>
Date: Mon, 14 Sep 2026 16:15:25 +0200
Subject: [PATCH] fix: Ingress-Zeitlimits und Speicherbudget fuer den
 Video-Upload setzen
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Zwei Einstellungen im Deployment liessen einen Video-Upload scheitern,
bevor die Anwendung ueberhaupt antworten konnte — beide Male mit einer
HTML-Fehlerseite, die im Browser als "Unexpected token '<'" ankam:

1. Der Ingress trug keinerlei Timeout-Annotation. ingress-nginx wartet
   dann nur 60 Sekunden je Phase und liefert danach eine eigene
   HTML-504-Seite. Ein Video-Upload braucht regelmaessig laenger: erst
   muessen bis zu 100 MB ueber die Leitung, danach rechnet ffmpeg das
   Video fuers Web um. proxy-read-timeout und proxy-send-timeout stehen
   jetzt auf 600s — bewusst oberhalb des harten ffmpeg-Zeitlimits von 5
   Minuten, damit im Zweifel die Anwendung selbst mit einer verwertbaren
   JSON-Meldung abbricht statt nginx die Verbindung zu kappen.

2. Das Speicherlimit von 512Mi war fuer einen 100-MB-Upload zu knapp:
   request.formData() laedt den multipart-Body vollstaendig in den
   Speicher, und der Kernel beendet den Prozess bei Ueberschreitung
   (OOMKilled). Limit auf 1Gi, Request auf 512Mi. Der CPU-Request steigt
   von 100m auf 500m, weil ffmpeg CPU-gebunden ist und mit 100m ein
   Vielfaches der Zeit braucht — bewusst weiterhin ohne CPU-Limit, das
   wuerde den Transcode auch auf einem freien Knoten drosseln.

Der Kommentar nennt zusaetzlich das davon unabhaengige Origin-Zeitlimit
eines vorgeschalteten CDN (bei Cloudflare 100 Sekunden, Fehler 524), das
sich hier nicht beeinflussen laesst.
---
 k8s/05-app-deployment.yaml | 26 +++++++++++++++++++++++---
 k8s/06-ingress.yaml        | 20 ++++++++++++++++++++
 2 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/k8s/05-app-deployment.yaml b/k8s/05-app-deployment.yaml
index 226df83..f01a44d 100644
--- a/k8s/05-app-deployment.yaml
+++ b/k8s/05-app-deployment.yaml
@@ -78,12 +78,32 @@ spec:
             initialDelaySeconds: 30
             periodSeconds: 30
             failureThreshold: 5
+          # Bemessen nach dem teuersten Vorgang der Anwendung, dem
+          # Admin-Video-Upload: Node laedt den multipart-Body beim
+          # request.formData() vollstaendig in den Speicher, und die Datei
+          # darf bis zu 100 MB gross sein (MAX_UPLOAD_VIDEO_BYTES in
+          # lib/uploads.ts). Zusammen mit dem Grundverbrauch des
+          # Next.js-Servers sprengte das ein Limit von 512Mi — der Kernel
+          # beendet den Prozess dann mitten im Upload (OOMKilled), und im
+          # Browser kommt davon nur die HTML-Fehlerseite des Reverse-Proxy an
+          # ("Unexpected token '<', "<!DOCTYPE "... is not valid JSON").
+          #
+          # Die Route selbst haelt inzwischen nur noch den Body im Speicher
+          # und streamt alles Weitere ueber die Platte (siehe
+          # app/api/admin/upload-video/route.ts) — 1Gi gibt darueber hinaus
+          # Reserve, damit ein zweiter gleichzeitiger Zugriff den Pod nicht
+          # kippt.
+          #
+          # ffmpeg ist CPU-gebunden: mit nur 100m dauert das Umrechnen ein
+          # Vielfaches und laeuft eher in ein Proxy-Zeitlimit. Bewusst KEIN
+          # CPU-Limit, nur ein hoeherer Request — ein Limit wuerde den
+          # Transcode hart drosseln, auch wenn der Knoten gerade frei ist.
           resources:
             requests:
-              cpu: 100m
-              memory: 256Mi
-            limits:
+              cpu: 500m
               memory: 512Mi
+            limits:
+              memory: 1Gi
       volumes:
         # Platzhalter — die Betreiberin ergaenzt hier ihre eigene
         # Volume-Quelle fuer den Namen "uploads" (z.B. ein PVC, das gegen
diff --git a/k8s/06-ingress.yaml b/k8s/06-ingress.yaml
index 49264fb..402970d 100644
--- a/k8s/06-ingress.yaml
+++ b/k8s/06-ingress.yaml
@@ -27,6 +27,26 @@ metadata:
     # der beiden Limits (100 MB) plus etwas Spielraum fuer den
     # multipart/form-data-Overhead ab.
     nginx.ingress.kubernetes.io/proxy-body-size: "110m"
+    # Ohne diese drei Annotationen wartet ingress-nginx nur 60 Sekunden je
+    # Phase und liefert danach eine eigene HTML-Fehlerseite (504) aus. Der
+    # Video-Upload braucht regelmaessig laenger: erst muessen bis zu 100 MB
+    # ueber die Leitung, danach rechnet ffmpeg das Video fuers Web um (siehe
+    # lib/video-transcode.ts). Im Browser kam davon nur an, dass die Antwort
+    # kein JSON war ("Unexpected token '<', "<!DOCTYPE "... is not valid
+    # JSON") — die Ursache war daraus nicht ablesbar.
+    #
+    # 600s deckt den langsamsten realistischen Fall ab und liegt bewusst
+    # oberhalb des harten ffmpeg-Zeitlimits von 5 Minuten
+    # (TRANSCODE_TIMEOUT_MS in lib/video-transcode.ts): so bricht im Zweifel
+    # die Anwendung selbst mit einer verwertbaren JSON-Meldung ab, statt dass
+    # nginx die Verbindung vorher kappt.
+    #
+    # Achtung: sitzt zusaetzlich ein CDN davor (z.B. Cloudflare), gilt dessen
+    # eigenes Origin-Zeitlimit unabhaengig hiervon weiter — bei Cloudflare
+    # sind das 100 Sekunden (Fehler 524), ebenfalls als HTML-Seite.
+    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
+    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
+    nginx.ingress.kubernetes.io/proxy-connect-timeout: "60"
 spec:
   ingressClassName: nginx
   tls: