[Bug] Username change cannot be saved in Account Settings

[Clawiee]

Tags: bug, ui, ux
Quality Rating: ⭐ 7/10

---

Reporter: 鲁力 (ALineWalker)

Description

In the Account Settings page, modifying the username does not save successfully. The interaction for saving username changes appears to be broken — clicking the "保存" (Save) button does not persist the change.

Steps to Reproduce

1. Open the Clawith platform and navigate to Account Settings (账户设置)
2. Under "个人信息" (Personal Information), modify the "用户名" (Username) field
3. Click the "保存" (Save) button
4. Observe the result

Expected Behavior

The username change should be saved successfully, and the user should see a confirmation that the update was applied.

Actual Behavior

The username modification cannot be saved. The save interaction does not work as expected.

Screenshots

Additional Context

• The screenshot shows the Account Settings modal with fields: 用户名 (Username), 邮箱 (Email), and 显示名称 (Display Name).
• The user attempted to modify the username but the save operation failed or had no effect.

[Clawiee]

Update from Reporter (鲁力)

Bug behavior update: The save function appears to be intermittent / unstable rather than completely broken.

• Sometimes the username save works correctly ✅
• Sometimes it fails to save ❌

This suggests the issue may be related to:

• Race condition or timing issue in the save API call
• Intermittent backend/network errors
• Frontend state management inconsistency

Updated screenshot (save succeeded this time):

Severity reassessment: The intermittent nature makes this harder to reproduce but still impacts user experience — users cannot reliably save their username changes.

[Clawiee]

Hi @Clawiee 👋

Thanks for reporting this issue! I've reviewed the relevant source code to understand what might be happening.

Analysis

Backend (PATCH /auth/me) — The API endpoint looks correct:

• backend/app/api/auth.py — The update_me handler accepts a UserUpdate payload, validates username uniqueness, and persists changes via setattr + db.flush()
• backend/app/schemas/schemas.py — UserUpdate schema correctly includes username: str | None = None

Frontend (AccountSettingsModal) — The save logic in frontend/src/pages/Layout.tsx appears structurally correct:

1. Compares username state vs user?.username — if different, adds body.username = username
2. Sends PATCH /api/auth/me with the diff
3. On success, calls setUser(updated) to refresh the auth store

Possible Root Causes

Since the backend logic looks sound, the issue is likely on the frontend side. Here are a few hypotheses:

1. Auth store setUser not triggering re-render — If useAuthStore.setUser() doesn't properly replace the user object (e.g., shallow merge vs full replace), the modal may re-initialize with stale data on next open, making it appear that the save didn't work.

2. user prop stale in modal — The AccountSettingsModal receives user as a prop and initializes state with useState(user?.username || ''). If the parent's user reference doesn't update after setUser(updated), re-opening the modal would show old data.

3. Network error being silently swallowed — The catch block shows an error message, but if the error toast disappears after 3 seconds (setTimeout(() => setMsg(''), 3000)), a transient network failure might go unnoticed.

4. Username uniqueness conflict (409) — If the desired username is already taken, the backend returns a 409 error, which would be displayed briefly but might be missed.

Suggested Investigation

• Check the browser Network tab when clicking "保存" to see if the PATCH /api/auth/me request is actually sent and what the response is
• Verify that useAuthStore.setUser() properly replaces the user object (check the Zustand store implementation)
• Test whether the email and display_name fields save correctly — if they do but username doesn't, the issue is likely in the comparison logic username !== user?.username

---

This analysis was generated by reviewing the Clawith source code. I'm a project assistant bot — please let the maintainers confirm before taking action.

[jigangz]

I'd like to work on this. I'll submit a PR shortly.

[wisdomqin]

https://github.com/user-attachments/assets/e236cbf8-430b-424d-b594-ee0d134a8abf
应该没问题