Profile photos upload but do not save (appear blank) #90

New issue

Open

opened 2026-07-07 16:19:42 +12:00 by fastie81 · 2 comments

fastie81 commented

2026-07-07 16:19:42 +12:00

Owner

Problem (via Natasha McKee - WA)

Profile photos upload but don't save - still appear blank after upload.

Steps to Reproduce

Go to profile photo upload section
Select and upload a photo
Photo appears to upload successfully
Page refresh shows blank/no photo saved

Expected Behavior

Uploaded profile photos should persist and display after saving.

app/core/entities/models.py (Member/Profile model with photo field)
app/core/operations/member_ops.py (photo upload handling)
app/infrastructure/database/repositories/member_repo.py (photo storage)
frontend/src/pages/profile/ (photo upload component)
frontend/src/components/common/ (file upload component)

### Problem (via Natasha McKee - WA) Profile photos upload but don't save - still appear blank after upload. ### Steps to Reproduce 1. Go to profile photo upload section 2. Select and upload a photo 3. Photo appears to upload successfully 4. Page refresh shows blank/no photo saved ### Expected Behavior Uploaded profile photos should persist and display after saving. ### Related Files - `app/core/entities/models.py` (Member/Profile model with photo field) - `app/core/operations/member_ops.py` (photo upload handling) - `app/infrastructure/database/repositories/member_repo.py` (photo storage) - `frontend/src/pages/profile/` (photo upload component) - `frontend/src/components/common/` (file upload component)

fastie81 added the

labels

2026-07-07 16:19:42 +12:00

~~fastie81 referenced this issue 2026-07-09 10:07:22 +12:00~~

Phase 4 — Backup & Restore Multi-DB Support #109

fastie81 referenced this issue from a commit

2026-07-20 14:30:55 +12:00

feat(backup): Refactor system and club backup/restore for multi-tenancy (#109, #90)

fastie81 referenced this issue

2026-09-14 11:24:10 +12:00

fix(security): remove hardcoded secrets, add coverage gate, tighten dockerignore #142

fastie81 commented

2026-10-21 18:44:04 +13:00

Author

Owner

Investigation (21 Oct): prod logs show POST /api/members/71/photo -> 500 (5 attempts, 15 Oct 07:33-07:36) with UnboundLocalError: cannot access local variable 'member_ops'. Cause: a local from app.container import member_ops inside if role == 'Member': in MemberPhoto.post/.delete made member_ops function-local, so every non-Member role (admin, instructor etc.) crashed on upload/delete. No other photo errors in the 14 days of logs; GETs are all 200.

Fix: #143 merged to main (4057830): removed the two shadowing imports, plus regression tests tests/unit/test_member_photo_unbound.py (fail with 500 on old code, pass with fix). Also needed #144 (pin SQLAlchemy<2.1) to get CI green.

Status: live on the test box. NOT yet in production - prod only deploys on v* tags (prod still on ci-fec0175). Leaving this open until a release tag is deployed and a non-Member upload is confirmed. Note: the report says the upload 'appears to succeed' - if the UI shows success on a 500 that is a separate frontend error-handling gap worth a look.

**Investigation (21 Oct):** prod logs show `POST /api/members/71/photo` -> 500 (5 attempts, 15 Oct 07:33-07:36) with `UnboundLocalError: cannot access local variable 'member_ops'`. Cause: a local `from app.container import member_ops` inside `if role == 'Member':` in `MemberPhoto.post`/`.delete` made `member_ops` function-local, so every non-Member role (admin, instructor etc.) crashed on upload/delete. No other photo errors in the 14 days of logs; GETs are all 200. **Fix:** #143 merged to main (`4057830`): removed the two shadowing imports, plus regression tests `tests/unit/test_member_photo_unbound.py` (fail with 500 on old code, pass with fix). Also needed #144 (pin SQLAlchemy<2.1) to get CI green. **Status:** live on the test box. **NOT yet in production** - prod only deploys on `v*` tags (prod still on `ci-fec0175`). Leaving this open until a release tag is deployed and a non-Member upload is confirmed. Note: the report says the upload 'appears to succeed' - if the UI shows success on a 500 that is a separate frontend error-handling gap worth a look.

fastie81 commented

2026-10-21 19:11:44 +13:00

Author

Owner

Deployed to production: v3.4.10 (image ci-168f17c, healthy, 0 inner member_ops imports in the running code, no tracebacks since deploy). Leaving open for one real confirmation: ask the reporter (Natasha) or an admin to upload a photo and confirm it persists after refresh. If the UI showed success on the earlier 500s, that is a separate frontend error-handling gap and worth its own issue.

**Deployed to production: v3.4.10** (image `ci-168f17c`, healthy, 0 inner `member_ops` imports in the running code, no tracebacks since deploy). Leaving open for one real confirmation: ask the reporter (Natasha) or an admin to upload a photo and confirm it persists after refresh. If the UI showed success on the earlier 500s, that is a separate frontend error-handling gap and worth its own issue.