-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Big refactoring of the Inbox #443
Conversation
We now have a type that routes an activity through the registered handlers until one of them matches. Each Actor/Activity/Object combination is represented by an implementation of AsObject These combinations are then registered on the Inbox type, which will try to deserialize the incoming activity in the requested types. Advantages: - nicer syntax: the final API is clearer and more idiomatic - more generic: only two traits (`AsActor` and `AsObject`) instead of one for each kind of activity - it is easier to see which activities we handle and which one we don't
Codecov Report
@@ Coverage Diff @@
## master #443 +/- ##
===========================================
+ Coverage 29.66% 42.48% +12.81%
===========================================
Files 66 68 +2
Lines 7190 9314 +2124
===========================================
+ Hits 2133 3957 +1824
- Misses 5057 5357 +300 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first batch of comments, I'll run some tests this evening or tomorrow
And fix compilations issues that I didn't catch before ?
- Avoid panics - Don't search for AP ID infinitely - Code style issues
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to test each activities. Sending/receiving delete seems to not be working. Sending like/reshare/follow works, but not receiving them. I haven't tested some Undo because I wasn't able to create the related activity in the first place
Thanks for your review @fdb-hiroshima. I'll try to reproduce your issues and fix them, and maybe add tests for it in plume-models too. |
It should be implemented for any AP object. It allows to look for an object in database using its AP ID, or to dereference it if it was not present in database Also moves the inbox code to plume-models to test it (and write a basic test for each activity type we handle)
Replace Context with PlumeRockets (and use it for the API context too while we are at it)
I fixed all the conflicts, and now instead of using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
weak 👀
So I did some testing, and here are the results:
I will try to debug a bit more the errors I encountered. |
it would be cool if we could add a |
I think if we were on Gitlab we could just pull their Docker images… I really miss Gitlab CI. |
can't we do it the ugly way with some bash script? |
We could, but it would take a lot of time to install all the dependencies, and the CI already takes so long to run. |
i think we're starting to discuss integration tests, and it's not really fruitful in this PR. |
Update: I optimized the algorithm a little bit to avoid dereferencing the same object twice, fixed the space-in-username issue, and found why it was not possible to Undo Announce and Like from Pleroma. It was just not sending the activity to Plume because no one was following the Pleroma account on the Plume instance. It works fine if I follow my Pleroma account from Plume. I still created a bug report. So I think this PR is ready for another review. 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀
fn from_activity(c: &PlumeRocket, acct: CustomGroup) -> Result<Self> { | ||
let url = Url::parse(&acct.object.object_props.id_string()?)?; | ||
let inst = url.host_str()?; | ||
let instance = Instance::find_by_domain(&c.conn, inst).or_else(|_| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
out of scope for this pr, but we should consider a find_or_create
of some kind instead of find_by_domain.or_else(insert)
, so to not tie to much code from one part of the model to another
…n instead of map when possible
Federation with old PlumeSending activities
Receivingall right Federation with itself
pleromaSending activities
Receiving
|
#443 (comment) by the way if we manage to get some certificate we can use in tests, this is now probably possible with circleci |
and fix a typo in a constant name
@fdb-hiroshima The issues with Pleroma are normally fixed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Yay, Finally! Thank you @igalic and @fdb-hiroshima for reviewing this big PR! 😊 |
We now have a type that routes an activity through the registered handlers
until one of them matches.
Each Actor/Activity/Object combination is represented by an implementation of AsObject
These combinations are then registered on the Inbox type, which will try to deserialize
the incoming activity in the requested types.
Advantages:
AsActor
andAsObject
) instead of one for each kind of activity(sorry for the big diff once again 😕)