dodox/wgBill
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix Login Flow v2 timing out under Docker (single gunicorn worker)

Browse Source 
_pending_flows in app/auth.py is an in-memory dict, not shared across
processes. With --workers 2, /auth/login/start and the follow-up
/auth/login/poll calls could land on different worker processes, which
never see each other's flow_id, so login would intermittently or always
time out. Only surfaced under gunicorn (Docker); the dev server is a
single process so it never hit this.

Pin to a single worker (+ threads for request concurrency) so the shared
in-memory state is actually shared. Fine at this scale - household tool,
already SQLite-backed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011b5fAoenyLtvS54oztB7ib
This commit is contained in:
dodox
2026-08-30 16:17:53 +02:00
co-authored by Claude Sonnet 5
parent 0bab9690c6
commit d73c739492
1 changed files with 9 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend/Dockerfile
+9 -1
View File
@@ -20,4 +20,12 @@ EXPOSE 5000
# instance/ (sqlite db) and uploads/ (receipt photos) should be mounted as
# volumes - see docker-compose.yml - so they survive a container rebuild.
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "2", "--timeout", "60", "run:app"]
#
# --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).
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "1", "--threads", "4", "--timeout", "60", "run:app"]