[Bug] Non-admin users get 404 on all session requests in Docker multi-user deployment

[HarounKedri]

Do you need to file an issue?

• I have searched the existing issues and this bug is not already filed.
• I believe this is a legitimate bug, not just a question or feature request.

Describe the bug

When AUTH_ENABLED=true, non-admin users can log in successfully but cannot chat. Every session request returns 404 and the per-user workspace directory is never created on disk.

Steps to reproduce

1. Deploy via docker-compose.ghcr.yml with AUTH_ENABLED=true
2. Register first user via /register → becomes admin
3. Create a second user via /admin/users
4. Assign LLM model grant to the second user
5. Log in as the second user in an incognito window
6. Attempt to send a chat message

Expected Behavior

Non-admin user gets their own isolated workspace under multi-user// and can chat normally.

Related Module

Dashboard

Configuration Used

AUTH_ENABLED=true
NEXT_PUBLIC_AUTH_ENABLED=true
AUTH_SECRET=
LLM_BINDING=openai
LLM_MODEL=deepseek-v4-flash
LLM_HOST=https://api.deepseek.com/v1
EMBEDDING_BINDING=ollama
EMBEDDING_MODEL=nomic-embed-text

Logs and screenshots

Backend logs:
GET /api/v1/sessions/unified_XXXXXXXXX_XXXXXXXX HTTP/1.1" 404 Not Found

Disk check:
$ docker exec deeptutor find /app/data/multi-user -type f
(empty — directory never created)

Additional Information

• DeepTutor Version: v1.3.10
• Operating System: Ubuntu 24.04
• Deployment: Docker (docker-compose.ghcr.yml) on Hetzner CPX22
• Admin account works perfectly — chat, TutorBot, Knowledge all functional
• Auth/login/user management UI all work correctly
• Root cause traced to get_current_path_service() in multi_user/paths.py — get_current_user_or_none() returns None for non-admin users during session requests, falling back to single-user path service. The multi-user// workspace is never initialized.

[kychiu1]

Completed by Sandcastle.

Root cause: require_auth was a sync (def) function. FastAPI >= 0.100 runs sync dependencies in a thread pool, so set_current_user() modified the ContextVar in the thread's context copy — invisible to the async route handler. get_current_user_or_none() returned None, falling back to the admin PathService. Admin worked by coincidence (fallback points to data/ which matches admin workspace root). Non-admin users needed multi-user/<uid>/ but always got the admin fallback → 404 on every session request, workspace never created.

Fix: Changed require_auth and require_admin from def to async def so FastAPI runs them directly in the event loop, preserving ContextVar propagation to route handlers.

Tests added: 3 new tests verifying require_auth is async, sets the ContextVar correctly for non-admin users, and non-admin users get the correct user-scoped path service.

[kychiu1]

Completed by Sandcastle.

Root cause: require_auth was a sync (def) function. FastAPI >= 0.100 runs sync dependencies in a thread pool, so set_current_user() modified the ContextVar in the thread's context copy — invisible to the async route handler. get_current_user_or_none() returned None, falling back to the admin PathService. Admin worked by coincidence (fallback points to data/ which matches admin workspace root). Non-admin users needed multi-user/<uid>/ but always got the admin fallback → 404 on every session request, workspace never created.

Fix: Changed require_auth and require_admin from def to async def so FastAPI runs them directly in the event loop, preserving ContextVar propagation to route handlers.

Tests added: 3 new tests verifying require_auth is async, sets the ContextVar correctly for non-admin users, and non-admin users get the correct user-scoped path service.