-
Notifications
You must be signed in to change notification settings - Fork 5
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
src: lore_api_client: use color_eyre::Result #26
base: unstable
Are you sure you want to change the base?
Conversation
`FailedFeedRequest` now is a valid `Report` so can be used in `Result` type from color_eyre. All other changes are collateral.
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.
Hi @OJarrisonn, and thank you for this great PR! I've left some comments due to stuff that is kind of my fault 😬
In any case, I think we may need to discuss quickly offline, as I was testing this and getting some weird results. Maybe is my misunderstanding about the way erye
works, but I'll ping you later.
Thank you so much anyway, as this is a valuable change!
match failed_feed_request { | ||
FailedFeedRequest::UnknownError(error) => bail!("[FailedFeedRequest::UnknownError]\n*\tFailed to request feed\n*\t{error:#?}"), | ||
FailedFeedRequest::StatusNotOk(feed_response) => bail!("[FailedFeedRequest::StatusNotOk]\n*\tRequest returned with non-OK status\n*\t{feed_response:#?}"), | ||
FailedFeedRequest::EndOfFeed => (), | ||
} |
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 forgot to mention in our offline conversation that it is important for the caller to handle the variants of FailedFeedRequest
. Especially EndOfFeed
, which is an edge case when we navigate through the whole history of a list. Below, is an explanation of why we need to match here, but my bad on my end for not explaining this earlier... Try accessing a small list (I found the ath12k
to have ~1500 patchsets) and navigate to the end of the feed to see the panic happening (it may take a while without the VPN stuff we discussed).
Explanation:
Because of logic on the LoreSession
type, we make subsequent fetches until we hit the number of patchsets we want, so if the page size is 30 and there are 45 patchsets total on a list when the user prompts for the second page, the program would panic, as it would try to access something like this.
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.
So in this case, if the request returns an Err(EndOfFeed)
, this caller should return an Ok(()) rather than propagating the error
My fault, didn't read the code with enough attention
Err(failed_feed_request) => return Err(failed_feed_request), | ||
Err(failed_feed_request) => bail!(failed_feed_request), |
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.
Same here about recoverable errors.
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.
Same here about bailed errors still being recoverable
Hi @OJarrisonn, and thanks for the quick update!
Actually, for the caller we need to maintain the same previous handling of the |
Yes! After I posted the review I went and digged further and found that However, when I made allusion to "weird behavior" was because, even if we handle the |
FailedFeedRequest
now is a validReport
so can be used inResult
type from color_eyre.All other changes are collateral.
This is part of #2