@U0K064KQV this is a result of creating the URI itself : https://github.com/babashka/http-client/blob/main/src/babashka/http_client/internal.clj#L150 and happens even before making the request. Since the URI is wrong its thrown right away. You should have the same behaviour with the raw java 11 http client which this uses too. using something like should have the behaviour you're expecting.

Essentially for the java 11 http client, the request needs to be built before the client fires it in (a)sync and a valid URI is needed there.

tested this in https://github.com/schmee/java-http-clj and https://github.com/gnarroway/hato now, all have the same behaviour

Try:

(->> ["" ""]  (mapv #(http/get % {:async true})) (mapv deref))

Right, ok. It does make it a bit more cumbersome to handle errors, since the function is now both sync and async. You need to try/catch around the call and around the deref.

I've also noticed that some errors are returned as exceptions? Like if you get a 503 it's going to be wrapped in an exception, instead of showing up on :status

Execution error (ExceptionInfo) at babashka.http-client.interceptors/fn (interceptors.clj:200).
 Exceptional status code: 503

It seems the default interceptors throw on bad http status?

@U0K064KQV Yes, you can suppress this with :throw false

The exception info that is thrown still has the status code in the ex-data

What are the assumptions I can make then? That all possibly thrown errors are going to be wrapped in "ex-info" ? And everything except for a :status 200 is returned as an exception?

@U0K064KQV the exception in the first code sample is gonna happen regardless of sync or async calls though. you can treat that separately. as its not being thrown by the interceptors and happens even before the request is started.

So like, say for a robust run, I would want to query 1000 URLs, and I want to retry the ones that error on an error where it makes sense to retry, and I want to capture and log the ones that fail on an error that retrying has no chance of fixing. And for each I want to also know what on the error I need to capture to be able to debug it later. I would need to know like where can errors be thrown/returned, what exact errors, which one make sense to retry, which one makes sense to skip and log, and for each type of error, where in the error is the important debug information so I can extract it and log it. How would I go about doing that now? It seems I would at least need documented description of where errors are thrown/returned, the set of all possible type of errors at each point, and their structure. At the minimum maybe a more generic description that like all errors will always be an ex-info and the type of error will be on a :type key on the ex-data, with the set of possible types, and that there will always be an ex-data with details. That way I could try/catch at the call to get and on the deref, inspect the ex-data :type key, if it's a retryable type I could retry the get, if it's not I would log the ex-data and ex-message and continue. I need at least this kind of guaranteed structure on all errors to be able to handle all of them. If some errors might not be ex-info, might not have a :type on ex-data, etc., it gets very tricky for the user.

Feel free to post issues with concrete problems you experienced in real programs. Would also be good to compare with what other clients are doing at the moment.

Well, that's a real issue I'm experiencing now 😛 I can't add robust error handling.

I'm also confused why this throws:

(->> [""
      ""
      ""
      ""
      "garbage"]
     (mapv #(try (http/get % {:async true})
                 (catch Exception e (delay e))))
     (mapv deref))

I'm in a hurry right now, so I can't help you, but if you want to record any useful details in an issue along with a proposal, that might get us somewhere some time

Sounds good, thanks!

deref-ing a future in which an exception happened throws, this is standard clojure / Java behavior

Ah, maybe I was getting it confused with taking from a channel

Also if it helps these are the only two places where exceptions are explicitly thrown as ex-infos: • https://github.com/babashka/http-client/blob/main/src/babashka/http_client/interceptors.clj#L200 • https://github.com/babashka/http-client/blob/main/src/babashka/http_client/internal.clj#L119 rest all would be an internal implementation exceptions if any, which may not be ex-infos. this does not anticipate every possible exceptions nor does it have a wrap all try

https://github.com/babashka/http-client/issues/11

Thanks for the issue, I'll think more about it

you escaped the sudo string in Justfile, but not in bb tasks

Try this for debugging:

(shell "ssh -t user@server \"echo 'service myservice restart'\"")

Ah, should've caught that, thanks. However, strangely enough, the fixed version yields the exact same error:

restart {
    :task (shell "ssh -t user@server \"sudo sh -c 'service myservice restart'\"")
}

Ah, got it, this works:

restart {
    :task (shell "ssh -t user@server 'sudo sh -c \"service myservice restart\"'")
}

Ah, I think you may have hit a bug in the one you posted first after my reply:

user=> (p/tokenize "ssh -t user@server \"sudo sh -c 'service myservice restart'\"")
["ssh" "-t" "user@server" "sudo sh -c service myservice restart"]
user=> (p/tokenize "ssh -t user@server 'sudo sh -c \"service myservice restart\"'")
["ssh" "-t" "user@server" "sudo sh -c \"service myservice restart\""]

Another way to solve it is:

(shell "ssh" "-t" "user@server" ...)

Posted the issue here: https://github.com/babashka/process/issues/100

Thanks - and a more general thanks for your work on Babashka, I've enjoyed using it so far!