Conversation
Code copy only to make it easier in the next patch to see what the changes are for async.
Remove code related to fuzzing from the new async files. Fuzzing of the async client can be added back later if needed.
In preparation for adding another async client change the Debug impl to refer to the local sync Client so that there is no conflict when adding the second async Client struct.
|
|
||
| impl BitreqHttpTransport { | ||
| /// Constructs a new [`BitreqHttpTransport`] with default parameters. | ||
| pub fn new() -> Self { BitreqHttpTransport::default() } |
There was a problem hiding this comment.
Just a comment. Should we consider some validation here? So that the user cannot shoot themselves on the foot like:
use jsonrpc::bitreq_http_async::Builder;
Builder::new().url("not_a_url").is_ok();I suppose a validation could happen at new or at fn build(self). No change required, because sync client also does it too. But it's a thought for production.
There was a problem hiding this comment.
Raise an issue man, your thoughts are valuable and will be lost if left here!
There was a problem hiding this comment.
Worth raising an issue. But not_a_url is a valid URL. I'm not sure what validation would be reasonable.
|
Since we are going to cut a release that includes code I know nothing about (async) I'd love to see PRs up that test everything before we release. Would you consider doing:
Then with green CI on those two PRs we'd have confidence we got things right and we can go ahead and cut the releases. And if someone with |
|
@satsfy have you spent much time with |
4 participants
Pulled out of #505 and polished.
The aim is to add async support without breaking existing sync downstream. This includes keeping the reexports of the current sync
Clientat the crate root.