-
Notifications
You must be signed in to change notification settings - Fork 55
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
Resolve unwrap in build body and when acquiring RwLock #79
Resolve unwrap in build body and when acquiring RwLock #79
Conversation
f53b6c3
to
4b432fa
Compare
Curious: why not use tokio's |
CHANGELOG.md
Outdated
@@ -1,5 +1,9 @@ | |||
# Changelog | |||
|
|||
## Unreleased | |||
|
|||
- fix: Avoid panics when acquiring a RwLock<_> and when building HTTP requests |
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.
Looks like breaking change; we should bump to 0.7.0. I will do after merging
The maintainers of tokio itself say that one should not use the async version of Mutex / RwLock without having reason for that: link. The same can very likely also be said about RwLock. For this reason, I think it's better to use parking_lot. |
Please resolve conflicts :) |
- Add error::Error variant - Add test for an invalid request
4b432fa
to
8fabb9e
Compare
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.
Thanks!
Description
The current version does panic if a RwLock is poisoned and also when a HTTP request could not be constructed from the given user data.
This PR replaces the RwLocks with the ones from parking_lot that do not have poison errors and adds propagation of errors happening when building the http request.
Resolves #69
How Has This Been Tested?
A test has been written for the invalid payload.
Due Dilligence