From 69ecc7fc6768ace9a670fc44dc616df7a9e10f8f Mon Sep 17 00:00:00 2001 From: Dominik Roth Date: Sun, 30 Aug 2026 16:19:20 +0200 Subject: [PATCH] Dockerfile: call out multi-process limitation explicitly The reasoning for --workers 1 was already there; adding an upfront note that this app doesn't support multi-process/multi-replica deployment as-is, since Login Flow v2's in-flight state is in-process memory - not just a gunicorn flag choice, a structural constraint until that state moves somewhere shared. --- backend/Dockerfile | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/backend/Dockerfile b/backend/Dockerfile index 2bfd8ee..b325dec 100644 --- a/backend/Dockerfile +++ b/backend/Dockerfile @@ -21,11 +21,17 @@ EXPOSE 5000 # instance/ (sqlite db) and uploads/ (receipt photos) should be mounted as # volumes - see docker-compose.yml - so they survive a container rebuild. # -# --workers 1: the Login Flow v2 poll state (app/auth.py _pending_flows) is -# an in-memory dict, not shared across processes - with >1 worker, -# /auth/login/start and the follow-up /auth/login/poll calls can land on -# different worker processes, which never see each other's flow_id, so -# login intermittently/always times out. Single worker (+ threads for -# concurrency) keeps that state actually shared. Fine for this scale -# (household tool, already SQLite-backed). +# NOTE: this app does not support running as multiple processes. Login Flow +# v2's in-flight state (app/auth.py _pending_flows) is a plain in-memory +# dict, not shared across processes/machines - it only works because every +# request within a login attempt is guaranteed to hit the same process. +# Scaling this out (more gunicorn workers, multiple replicas, etc.) would +# need that state moved to somewhere shared (the sqlite db, redis, ...) +# first. +# +# --workers 1: with >1 worker, /auth/login/start and the follow-up +# /auth/login/poll calls can land on different worker processes, which +# never see each other's flow_id, so login intermittently/always times out. +# Single worker (+ threads for concurrency) keeps that state actually +# shared. Fine for this scale (household tool, already SQLite-backed). CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "1", "--threads", "4", "--timeout", "60", "run:app"]