_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
- backend/Dockerfile: gunicorn, not the dev server.
- frontend/Dockerfile: multi-stage, nginx serves the static build.
- nginx.conf proxies /api and /auth to the backend so both services
share one origin - keeps the session cookie simple first-party,
no SameSite=None/CORS complexity in production.
- docker-compose.yml: bind-mounts ./data/{instance,uploads} (not
named volumes) so the sqlite db and uploaded photos are visible
under the project dir; :Z flag for SELinux-enforcing hosts
(Fedora/RHEL) - without it gunicorn fails with "unable to open
database file".
- FRONTEND_PORT env var to pick the exposed port.
- .env.example: documents CORS_ORIGIN is moot in the compose setup
(same-origin via nginx) and that SESSION_COOKIE_SECURE=true needs
a TLS-terminating reverse proxy in front in real deployment.
Verified: both images build clean, full stack up via docker compose,
login flow starts for real against the actual NC instance through
the nginx proxy, sqlite db persists to the bind mount correctly.
dodoxandClaude Sonnet 5