dbprune: add --keep-followed and don't prune pinned posts by default #897
No reviewers
Labels
No labels
approved, awaiting change
broken setup
bug
cannot reproduce
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
not our bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
AkkomaGang/akkoma!897
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "Oneric/akkoma:mix-prune_newopts"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This allows keeping posts and boosts from followed remote actors regardless of age, or optionally everything they interacted with (like, emoji react, ...).
Furthermore, pinned posts are now no longer pruned by default which should avoid the refetch surge afterwards. If someone really wants to there’s a setting to keep pruning them however.
Unlike other criteria pinned posts being protected does not extend to their threads, even with
--keep-threads; if someone really wants to they can try adding this, but I think it should be kept separate from--keep-threads. I use--keep-threadsbut do not care about preserving threads of pinned posts of some random remote user i might have never actually looked at. Implementing it similar to--keep-followed {posts,full,none}seems best (if done at all).Given the query planner already struggled with this version of pinned-post protection a thread-aware version might be even more finicky to get right.
It not protecting threads of pinned posts by default also matches better with previous behaviour
274c16aab1516827c356Merging as it has tests, worked fine for me (, as a mix task can't interfere with regular usage) and to to spare admins from continuing to suffer from a post-prune refetch onslaught