Keep saved named-group rosters out of message history - #176
Merged
Merged
Conversation
blueferry.config derives its default configuration and state paths from the real XDG directories at import. A test that undid its own isolation (for example with monkeypatch.undo()) fell back to the operator's real history, contact cache, settings, and local.env. Point XDG_CONFIG_HOME, XDG_STATE_HOME, and XDG_RUNTIME_DIR at a throwaway tree before anything imports blueferry, as the suite already does for D-Bus addresses.
Addresses the roster loss in #174. A confirmed reply roster for a named group was appended to history as an ordinary event, so it was lost in three ways while the group was still active: - conversations are projected from only the newest 2,000 history events, so after roughly 1,000 messages the saved roster fell out of view and the thread asked for participants again; - the 30-day retention sweep deleted it outright; - the re-prompt was pre-filled only with senders still in the window, so members appeared to disappear over time. Store rosters as an encrypted preference in settings.json, like starred threads and group confirmations, and apply them to every projection. Storage preparation moves rosters saved by older releases out of history before pruning. Deleting a conversation, clearing history, or changing the storage mode still removes its roster.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses the "keeps losing group members" part of #174.
The bug
When you confirm a reply roster for a named group,
set_group_participantssaved it to history as an ordinarygroup_routeevent. That makes it disposable while the group is still in use:MAX_CONVERSATION_EVENTS). Each group message is two events (MAP + ANCS), so after roughly 1,000 messages the saved roster fell out of view and the thread went back to asking for participants.seen_attimestamp, so the 30-day sweep deleted it outright.The fix
GroupRoutesStore(group_routes.py) keeps one roster per named-group key as an encrypted preference insettings.json, like starred threads and group confirmations. It is bounded to 200 rosters.group_routeevents out of history before pruning. If a roster was saved in both places, the store's copy wins.Also in this PR
Keep tests away from the operator's BlueFerry state: conftest now pointsXDG_CONFIG_HOME,XDG_STATE_HOME, andXDG_RUNTIME_DIRat a throwaway directory before anything importsblueferry. Previously, a test that undid its own monkeypatching (for example withmonkeypatch.undo()) fell back to the real~/.local/state/blueferryand loaded the reallocal.env. This happened once during development; nothing was modified.Not addressed
Group messages still land in one-to-one threads whenever the matching ANCS notification is missing. MAP carries no group identity, so nothing can be fixed on the BlueFerry side without more information. The README now explains this.
Validation