LotusGuild/cinny
3
0
Fork 0
Code Issues 27 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

Quick statuses in General Settings not auto clearing after set interval #227

New Issue
Closed
opened 2026-09-21 18:54:22 -04:00 by jared · 1 comment
jared commented 2026-09-21 18:54:22 -04:00
Owner
Copy Link
Copy Source

Have claude deep dive this

Have claude deep dive this
jared added the bugarea: settingspriority: medium labels 2026-09-21 18:54:43 -04:00
jared commented 2026-09-23 15:42:00 -04:00
Author
Owner
Copy Link
Copy Source

Deep dive done — reproduced and fixed in e393c45f.

Root cause. The auto-clear (StatusExpiryMonitor, ClientNonUIFeatures.tsx:375) did this, in this order:

localStorage.removeItem(msgKey);
localStorage.removeItem(expiryKey);
mx.setPresence({ …, status_msg: '' }).catch(() => undefined);   // ← swallowed

It threw away the record before the write and swallowed any error. Synapse rate-limits presence to ~1 write per 10 s per user (rc_presence, the same limit behind #226) and our own presence heartbeat spends that budget, so a 429 here is routine — especially at startup, where the monitor's first check() fires right next to the initial heartbeat. One 429 and the clear was gone forever: the server kept the status and nothing local remembered it was supposed to expire.

Reproduced headlessly by injecting three 429s on the presence PUT: the status stayed 🎮 Gaming on the server indefinitely while lotus-status-* in localStorage was already empty — no retry, no second chance, exactly the symptom.

Fix. The clear now goes through setPresenceWithRetry (the #226 helper — honours retry_after_ms, bounded wait) and only removes the localStorage keys after the server has taken the write; a re-entry guard prevents overlapping attempts, and the poll interval is 15 s (was 30 s) so a retry lands promptly. Re-ran the same 429 injection: the status clears.

Two things that remain by design, worth knowing:

  • The expiry is device-local. If you set a status and never open Lotus again, nothing clears it — the next launch does (the monitor checks once on mount).
  • A status set on device A expires on device A's timer; device B has no record of it. Making that server-side would need a custom account-data event; say the word if you want it.
Deep dive done — reproduced and fixed in e393c45f. **Root cause.** The auto-clear (`StatusExpiryMonitor`, `ClientNonUIFeatures.tsx:375`) did this, in this order: ```ts localStorage.removeItem(msgKey); localStorage.removeItem(expiryKey); mx.setPresence({ …, status_msg: '' }).catch(() => undefined); // ← swallowed ``` It threw away the record **before** the write and swallowed any error. Synapse rate-limits presence to ~1 write per 10 s per user (`rc_presence`, the same limit behind #226) and our own presence heartbeat spends that budget, so a 429 here is routine — especially at startup, where the monitor's first `check()` fires right next to the initial heartbeat. One 429 and the clear was gone forever: the server kept the status and nothing local remembered it was supposed to expire. **Reproduced** headlessly by injecting three 429s on the presence PUT: the status stayed `🎮 Gaming` on the server indefinitely while `lotus-status-*` in localStorage was already empty — no retry, no second chance, exactly the symptom. **Fix.** The clear now goes through `setPresenceWithRetry` (the #226 helper — honours `retry_after_ms`, bounded wait) and only removes the localStorage keys **after the server has taken the write**; a re-entry guard prevents overlapping attempts, and the poll interval is 15 s (was 30 s) so a retry lands promptly. Re-ran the same 429 injection: the status clears. **Two things that remain by design**, worth knowing: - The expiry is device-local. If you set a status and never open Lotus again, nothing clears it — the next launch does (the monitor checks once on mount). - A status set on device A expires on device A's timer; device B has no record of it. Making that server-side would need a custom account-data event; say the word if you want it.
jared closed this issue 2026-09-23 15:42:00 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
a11y
Accessibility: keyboard, screen reader, contrast, motion
 area: appearance
Client area: appearance
 area: auth-session
Client area: auth-session
 area: build-ci
Client area: build-ci
 area: calls
Client area: calls
 area: desktop
Client area: desktop
 area: media
Client area: media
 area: messaging
Client area: messaging
 area: mobile
Client area: mobile
 area: moderation
Client area: moderation
 area: navigation
Client area: navigation
 area: notifications
Client area: notifications
 area: settings
Client area: settings
 area: threads
Client area: threads
 bug
Something is not working
 dependencies
Third-party package versions and advisories
 docs
README / LOTUS_* docs wrong or missing
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 needs-human-review
performance
Re-render storms, leaks, heavy work on hot paths
 planning
priority: critical
Data loss, security hole, or crash on a main path
 priority: high
Broken feature or serious usability problem
 priority: low
Minor issue or polish
 priority: medium
Wrong behaviour in an edge case or notable degradation
 qa
Manual QA: shipped, needs a human in a real environment
 question
More information is needed
 research
security
XSS, unsafe URLs, data leaks, auth/session
 tech-debt
Code health, dead code, fragile patterns
 ux
Usability or visual inconsistency
 wontfix
This won't be fixed
No labels area: settings bug priority: medium
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
cole (Cole Keller) jared (Jared Vititoe) nathan (Nathan Vititoe)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: LotusGuild/cinny#227