gix::transport::client::blocking_io::http::reqwest::Remote errors too late

[Jake-Shadle]

Duplicates

• I have searched the existing issues

Current behavior 😯

If there is a problem setting up the client, the thread will exit with an error and the channels owned by the thread will be dropped, which will cause panics when the remote tries to be used, such as here.

Expected behavior 🤔

If there is an error setting up the client or other setup issues, I would expect to have a proper error returned from the higher level function (in this case fetch_only) rather than a panic, as it would make it much more clear to users what the root cause of the failure is, as well as not (potentially) bring down their entire application.

This comment also seems misleading.

Steps to reproduce 🕹

1. Induce a failure in reqwest's clientbuilder, in my case, apparently trust-dns can no longer parse my resolv.conf, there are multiple other ways for it to fail though, unsure what the easiest method to induce failure would be
2. Do a remote operation eg. gix::prepare_clone().fetch_only()
3. Observe panic trying to send the request since thread with the client was dropped and there is no request receiver.

[Byron]

Thanks for reporting, it's much appreciated!
I wasn't aware, and apparently the comment indicates that it was supposed to work that way (and maybe even does for curl), but doesn't anymore. Maybe it never worked and a test is missing, and I will see to sorting that out soon.

[Byron]

This will be fixed with the next release, I will post here when that happens and it should be today or tomorrow.

[Byron]

This issue is resolved with the latest release.
Since this backend is rather young and not really used by me, I think it will mostly be user requests that make it better. So please keep them coming if there is a need.