Reviewers
Request review
No reviewers
Labels
Clear labels
Related to the REST API
Code running on the server
Stuff related to Federation
Related to the front-end
Translations, and related code
More about project management or code than the project itself
The building, or installation process of Plume
Something isn't working
We need to talk
New feature or request
This is a new feature
Compatibility with different browsers, readers and OS
Related to an external package that Plume uses
UI/UX related issues and PRs
Good for newcomers
Extra attention is needed
Issues affecting only mobile UX
How elements're rendered out for the end user
Something else needs to be fixed first
This issue or pull request already exists
This PR is not complete yet
Issues concern a limited number of instances
This doesn't seem right
Need to be discussed by the community (on Loomio)
This PR is ready to be reviewed
Proposed ideas worth considering
This is issue has been created after a vote on Loomio
This will not be worked on
Apply labels
A: API
Related to the REST API
A: Backend
Code running on the server
A: Federation
Stuff related to Federation
A: Front-End
Related to the front-end
A: I18N
Translations, and related code
A: Meta
More about project management or code than the project itself
A: Security
Build
The building, or installation process of Plume
C: Bug
Something isn't working
C: Discussion
We need to talk
C: Enhancement
New feature or request
C: Feature
This is a new feature
Compatibility
Compatibility with different browsers, readers and OS
Dependency
Related to an external package that Plume uses
Design
UI/UX related issues and PRs
Documentation
Good first issue
Good for newcomers
Help welcome
Extra attention is needed
Mobile
Issues affecting only mobile UX
Rendering
How elements're rendered out for the end user
S: Blocked
Something else needs to be fixed first
S: Duplicate
This issue or pull request already exists
S: Incomplete
This PR is not complete yet
S: Instance specific
Issues concern a limited number of instances
S: Invalid
This doesn't seem right
S: Needs Voting/Discussion
Need to be discussed by the community (on Loomio)
S: Ready for review
This PR is ready to be reviewed
Suggestion
Proposed ideas worth considering
S: Voted on Loomio
This is issue has been created after a vote on Loomio
S: Wontfix
This will not be worked on
No Label
A: API
A: Backend
A: Federation
A: Front-End
A: I18N
A: Meta
A: Security
Build
C: Bug
C: Discussion
C: Enhancement
C: Feature
Compatibility
Dependency
Design
Documentation
Good first issue
Help welcome
Mobile
Rendering
S: Blocked
S: Duplicate
S: Incomplete
S: Instance specific
S: Invalid
S: Needs Voting/Discussion
S: Ready for review
Suggestion
S: Voted on Loomio
S: Wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
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: Plume/Plume#392
Reference in New Issue
There is no content yet.
Delete Branch 'result'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
Result
as much as possibleTODO (maybe in another PR? this one is already quite big):
Result<X, ErrorPage>
instead of panicking when we have anError
(sorry, this isn't going to be fun to review, the diff is huge, but it is always the same changes)
I guess it wasn't fun to write either
first pass, not done yet
@ -122,3 +122,3 @@
act["@context"] = context();
let signed = act.sign(sender);
let signed = act.sign(sender).expect("activity_pub::broadcast: signature error");
i thought we're trying to avoid panics?
@ -107,3 +107,3 @@
pub fn signature<S: Signer>(signer: &S, headers: &HeaderMap) -> HeaderValue {
pub fn signature<S: Signer>(signer: &S, headers: &HeaderMap) -> Result<HeaderValue, ()> {
let signed_string = headers
can you briefly explain this return signature?
maybe then I'll also understand the above
expect()
@ -214,0 +170,4 @@
// We don't really care about all the following for remote instances
long_description: SafeString::new(""),
short_description: SafeString::new(""),
default_license: String::new(),
wow! that's some really nice refactoring! 👍
so, it's ok, or desired, that tests panic, right?
neat!
https://doc.rust-lang.org/std/result/enum.Result.html#method.map_err i read the doc, but still don't understand what this does
I you understand
map
, this is basically the same thing, but forErr(_)
instead ofOk(_)
. And passingError::from
is the equivalent to|e| e.from()
This is just mapping an error type to another
@ -122,3 +122,3 @@
act["@context"] = context();
let signed = act.sign(sender);
let signed = act.sign(sender).expect("activity_pub::broadcast: signature error");
Ahah, right… It actually doesn't add a panic, we just panic "outside" of the function instead of "inside" because it wouldn't make much sense to return a
Result
frombroadcast
as it is always the main function of its thread.@ -107,3 +107,3 @@
pub fn signature<S: Signer>(signer: &S, headers: &HeaderMap) -> HeaderValue {
pub fn signature<S: Signer>(signer: &S, headers: &HeaderMap) -> Result<HeaderValue, ()> {
let signed_string = headers
It says that it can either success with a
HeaderValue
, or fail with()
, so we don't have much details about the error, we just know it failed, but it is probably enough to know that something failed in this function (or maybe not?)Yes, tests should panic every time something is wrong, so that they fail and that we now something is broken.
Codecov Report
It seems good.
Some Result could/should be Result<()> instead.
The
?
syntax is really helpful with error handlingI could see a use for knowing how many posts were deleted, and at first at assumed it's what it was. But after re-reading it's telling how many blogs where deleted, so the Ok(_) will only be 1 any, am I right?
If I'm not mistaken, the usize is going to be how many entries were affected, which is one?
If I'm not mistaken, the usize is going to be how many entries were affected, which is one?
I don't know if there are other places where
unwrap_or_else(|_| ..)
was replaced withunwrap_or(..)
, if so this comment also apply to them. I think it would be better toor_else(|_| ..)?
, I think you already did it at other placesSame about returning Result<()> because it will be 1
same about
Result<()>
Same about
Result<()>
Same about
Result<()>
I should have made this message from the start. Maybe add something about making sure no other instance of plume is already running here?
Yes, this result is not used anywhere, it just to have the right return type without having to
.map(|_| ())
, but maybe it's misleading?Yes, but https://github.com/Plume-org/Plume/pull/392#discussion_r244369771
I think it is, even more because we did not document any function (nor what they return)
Ok, I'll change it then. 👍
👍
Reviewers
80a4dae8bd
.Step 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Forgejo.