On mount, ProfileDecoration fetches /profile/{userId} to learn the user's current decoration. Any failure (offline, slow network, transient 5xx, homeserver rate limit) is caught and unconditionally sets both current and selected to null — i.e. the UI renders "None" with no error or retry affordance, even though the server-side decoration is untouched. This is exactly the "UI state disagrees with stored state" pattern called out in the audit brief.
How to trigger
Open Settings → Profile → Avatar Decoration while offline or with the request failing; the panel shows "None" although a decoration is actually set. If the user then picks a different decoration (or explicitly clicks "None") based on this wrong display and saves, the real decoration is overwritten based on incorrect displayed state.
Suggested fix
Distinguish "confirmed no decoration" from "failed to load" — show an inline error/retry state instead of silently defaulting to null on network failure.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** medium · **Type:** bug · **Confidence:** high
**Location:** `src/app/features/settings/account/ProfileDecoration.tsx:71-86`
### Problem
On mount, `ProfileDecoration` fetches `/profile/{userId}` to learn the user's current decoration. Any failure (offline, slow network, transient 5xx, homeserver rate limit) is caught and unconditionally sets both `current` and `selected` to `null` — i.e. the UI renders "None" with no error or retry affordance, even though the server-side decoration is untouched. This is exactly the "UI state disagrees with stored state" pattern called out in the audit brief.
### How to trigger
Open Settings → Profile → Avatar Decoration while offline or with the request failing; the panel shows "None" although a decoration is actually set. If the user then picks a different decoration (or explicitly clicks "None") based on this wrong display and saves, the real decoration is overwritten based on incorrect displayed state.
### Suggested fix
Distinguish "confirmed no decoration" from "failed to load" — show an inline error/retry state instead of silently defaulting to null on network failure.
---
_Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._
jared
added this to the Audit 2026-09 · Medium & Low milestone 2026-09-12 01:51:12 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: medium · Type: bug · Confidence: high
Location:
src/app/features/settings/account/ProfileDecoration.tsx:71-86Problem
On mount,
ProfileDecorationfetches/profile/{userId}to learn the user's current decoration. Any failure (offline, slow network, transient 5xx, homeserver rate limit) is caught and unconditionally sets bothcurrentandselectedtonull— i.e. the UI renders "None" with no error or retry affordance, even though the server-side decoration is untouched. This is exactly the "UI state disagrees with stored state" pattern called out in the audit brief.How to trigger
Open Settings → Profile → Avatar Decoration while offline or with the request failing; the panel shows "None" although a decoration is actually set. If the user then picks a different decoration (or explicitly clicks "None") based on this wrong display and saves, the real decoration is overwritten based on incorrect displayed state.
Suggested fix
Distinguish "confirmed no decoration" from "failed to load" — show an inline error/retry state instead of silently defaulting to null on network failure.
Filed from the September 2026 client audit (branch
lotus@4bea4895).