This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-24
Channels
- # announcements (22)
- # babashka (33)
- # babashka-sci-dev (161)
- # beginners (25)
- # calva (57)
- # cider (6)
- # clara (6)
- # clerk (14)
- # clj-kondo (24)
- # clojars (10)
- # clojure (65)
- # clojure-austin (1)
- # clojure-conj (2)
- # clojure-europe (23)
- # clojure-miami (3)
- # clojure-nl (3)
- # clojure-norway (3)
- # clojure-uk (3)
- # clojurescript (28)
- # cursive (24)
- # datomic (136)
- # emacs (38)
- # graalvm (29)
- # graphql (3)
- # introduce-yourself (8)
- # jackdaw (4)
- # jobs-discuss (9)
- # malli (5)
- # nbb (36)
- # off-topic (11)
- # pathom (58)
- # polylith (2)
- # practicalli (1)
- # re-frame (5)
- # reagent (11)
- # releases (1)
- # remote-jobs (8)
- # sci (15)
- # shadow-cljs (31)
- # slack-help (2)
- # spacemacs (11)
- # sql (7)
- # tools-build (9)
In babashka.http-client, it seems that when we use {:async true}, if an exception happen it's not isolated? I'm doing something like:
(->> ["garbage" ""]
(mapv #(http/get % {:async true})))
java.lang.IllegalArgumentException: URI with undefined scheme [at <repl>:4:8]
Where it seems like the error is not thrown in an async way? Shouldn't this return CompletableFuture? How is it that it throws?@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))
it will throw, without the last form it doesn'tRight, 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
@U0K064KQV Yes, you can suppress this with :throw false
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.
I'm also confused why this throws:
(->> [""
""
""
""
"garbage"]
(mapv #(try (http/get % {:async true})
(catch Exception e (delay e))))
(mapv deref))
I thought deref would return the exception as a value, but it seems it throws on exception?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
deref-ing a future in which an exception happened throws, this is standard clojure / Java behavior
Also if it helps these are the only two places where exceptions are explicitly thrown as ex-info
s:
• 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
A one-liner to run babashka tests with eftest (requires the latest bb version)
$ bb -Sdeps '{:paths ["src" "test"] :deps {eftest/eftest {:mvn/version "0.6.0"}}}' -e "(require '[eftest.runner :refer [find-tests run-tests]]) (run-tests (find-tests \"test\"))"
3/3 100% [==================================================] ETA: 00:00
Ran 3 tests in 0.026 seconds
19 assertions, 0 failures, 0 errors.
{:test 3, :pass 19, :fail 0, :error 0, :type :summary, :duration 26.077792}
As a Babashka/Clojure newbie, I'm trying to translate my justfile into Babashka tasks. I got stuck translating this recipe:
restart:
@ssh -t user@server "sudo sh -c 'service myservice restart'"
My Babashka translation:
restart {
:task (shell "ssh -t user@server sudo sh -c \"service myservice restart\"")
}
The justfile version works, whereas the Babashka version asks for the password but then exits with an error.
It prints:
"Usage: service < option > | --status-all | [ service_name [ command | --full-restart ] ]"
Any ideas about what the problem is?Try this for debugging:
(shell "ssh -t user@server \"echo 'service myservice restart'\"")
and then work from thereAh, 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\""]
I'll fix it in the next version of bbAnother way to solve it is:
(shell "ssh" "-t" "user@server" ...)
Only the first string is tokenizedPosted the issue here: https://github.com/babashka/process/issues/100