AkkomaGang/akkoma
AkkomaGang/akkoma
15
66
Fork 94
Code Issues 182 Pull requests 28 Projects 2 Releases 14 Packages Wiki Activity

mrf/object_age: fix handling of non-public objects #851

Open
Oneric wants to merge 1 commit from Oneric/akkoma:mrf-fix-oage into develop
pull from: Oneric/akkoma:mrf-fix-oage
merge into: AkkomaGang:develop
Conversation 0 Commits 1 Files changed 3 +29 -9
Oneric commented 2024-11-16 00:24:08 +00:00
Member
Copy link

Supersedes: #845

Currently logic unconditionally adds public adressing to "cc"
and follower adressing to "to" after attempting to strip it
from the other one. This is horrible for two reasons:

First the bug prompting this investigation and fix,
this creates duplicates when adressing URIs already
were in their intended final field; e.g. prominently
the case for all "unlisted" posts.
Since List.delete only removes the first occurence,
this then broke follower-adress stripping later on.

It’s also not safe in general wrt to non-public adressing:
e.g. pre-existing duplicates didn’t get fully stripped,
bespoke adressing modes with only one of public addressing
or follower addressing — and most importantly:
any belatedly received DM also got public adressing added!
Frighently this last point was actually checked as "correct" in tests
albeit this appears to be a mistake from mindless match adjustments
from when genuine crashes on nil adressing lists got fixed in
10c792110e.

Clean up this sloppy logic up, making sure all instances of relevant
adresses are purged and only readded when they actually existed to begin
with. To avoid problems with any List.delete usages remaining in other
places, also ensure we never create duplicate entries.

Supersedes: https://akkoma.dev/AkkomaGang/akkoma/pulls/845 --- Currently logic unconditionally adds public adressing to "cc" and follower adressing to "to" after attempting to strip it from the other one. This is horrible for two reasons: First the bug prompting this investigation and fix, this creates duplicates when adressing URIs already were in their intended final field; e.g. prominently the case for all "unlisted" posts. Since List.delete only removes the first occurence, this then broke follower-adress stripping later on. It’s also not safe in general wrt to non-public adressing: e.g. pre-existing duplicates didn’t get fully stripped, bespoke adressing modes with only one of public addressing or follower addressing — and most importantly: any belatedly received DM also got public adressing added! Frighently this last point was actually checked as "correct" in tests albeit this appears to be a mistake from mindless match adjustments from when genuine crashes on nil adressing lists got fixed in 10c792110e6ea8ed21f739ef8f4f0eff4659ebf9. Clean up this sloppy logic up, making sure all instances of relevant adresses are purged and only readded when they actually existed to begin with. To avoid problems with any List.delete usages remaining in other places, also ensure we never create duplicate entries.
👍 1
Oneric added 1 commit 2024-11-16 00:24:09 +00:00
mrf/object_age: fix handling of non-public objects
Some checks are pending
ci/woodpecker/pr/build-amd64 Pipeline is pending approval
Details
ci/woodpecker/pr/build-arm64 Pipeline is pending approval
Details
ci/woodpecker/pr/docs Pipeline is pending approval
Details
ci/woodpecker/pr/lint Pipeline is pending approval
Details
ci/woodpecker/pr/test Pipeline is pending approval
Details
e5e9f9aebd 
Currently logic unconditionally adds public adressing to "cc"
and follower adressing to "to" after attempting to strip it
from the other one. This is horrible for two reasons:

First the bug prompting this investigation and fix,
this creates duplicates when adressing URIs already
were in their intended final field; e.g. prominently
the case for all "unlisted" posts.
Since List.delete only removes the first occurence,
this then broke follower-adress stripping later on.

It’s also not safe in general wrt to non-public adressing:
e.g. pre-existing duplicates didn’t get fully stripped,
bespoke adressing modes with only one of public addressing
or follower addressing — and most importantly:
any belatedly received DM also got public adressing added!
Frighently this last point was actually checked as "correct" in tests
albeit this appears to be a mistake from mindless match adjustments
from when genuine crashes on nil adressing lists got fixed in
10c792110e.

Clean up this sloppy logic up, making sure all instances of relevant
adresses are purged and only readded when they actually existed to begin
with. To avoid problems with any List.delete usages remaining in other
places, also ensure we never create duplicate entries.
Oneric force-pushed mrf-fix-oage from e5e9f9aebd to 5a3c6a6896 2024-11-16 02:20:04 +00:00 Compare
Oneric force-pushed mrf-fix-oage from 5a3c6a6896 to 932810c35e 2024-11-16 23:52:14 +00:00 Compare
Some checks are pending
ci/woodpecker/pr/build-amd64 Pipeline is pending approval
Details
ci/woodpecker/pr/build-arm64 Pipeline is pending approval
Details
ci/woodpecker/pr/docs Pipeline is pending approval
Details
ci/woodpecker/pr/lint Pipeline is pending approval
Details
ci/woodpecker/pr/test Pipeline is pending approval
Details
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u mrf-fix-oage:Oneric-mrf-fix-oage
git checkout Oneric-mrf-fix-oage
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
approved, awaiting change

   
bug

Something is not working

  
configuration

This requires config changes

  
documentation

This is about human-readable docs

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
extremely low priority

   
feature request

Something new?

  
Fix it yourself

Support has been attempted

  
help wanted

Need some help

  
invalid

Something is wrong

  
mastodon_api

   
needs docs

   
needs tests

   
not a bug

   
planned

   
pleroma_api

   
privacy

   
question

More information is needed

  
static_fe

   
triage

   
wontfix

This won't be fixed

No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#851
No description provided.
Delete branch "Oneric/akkoma:mrf-fix-oage"

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?