-
Notifications
You must be signed in to change notification settings - Fork 32
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
Switch to reqwest #332
Switch to reqwest #332
Conversation
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.
+573 −1,050
Everybody liked that
(Except Clippy. Clippy has no chill.)
I gave this a quick read and it really seems to simmer the code down nicely!
I will stop with the bike-shedding now... =D
I have ruined my statistics a little bit by introducing a better abstraction for handling errors (which means we don't have duplicated logic in I think this is ready for review, I will not touch this PR again before it becomes an insatiable monster. I still believe it is quite OK to test and will be running |
Haven't looked into detail too much yet, but this looks very good already. I suggest we also make a WF build with this and run it some days. |
Whisperfish tests: https://gitlab.com/whisperfish/whisperfish/-/merge_requests/639 |
Switch the concrete implementation of both the HTTP client to
reqwest
andreqwest-websocket
which are powered behind the scenes by exactly the same libraries we are currently using (namely,hyper
andtokio-tungstenite
).PushService.kt
).reqwest::Client
is now shared by both HTTP requests and the Websocketsink
andstream
in the websocket impl (since you don't have to forward messages to the concrete implementation)SignalServiceResponse
which is implemented for bothreqwest::Response
andWebSocketResponseMessage
to let us share the HTTP status error handling (the one that handles mismatched sessions, etc.) - this is IMO a big improvement and will avoid any sort of drifting in the future