babashka 2023-12-27 | Slack Archive

I'm using babashka.curl/request to do a patch request with a map like this:

{:headers
 {"Accept" "application/vnd.pulumi+8",
  "Content-Type" "application/json",
  "Authorization" "token XXX"},
 :url "",
 :body
 "{\"addStackPermission\":{\"projectName\":\"my-project\",\"stackName\":\"my-stack\",\"permission\":101}}",
 :method :patch}

If myteam (in the URL) is invalid, an exception is thrown:

; java.util.concurrent.ExecutionException: babashka.curl: status 404 user /Users/my-user/Code/my-org/flashcli/src/pulumi.clj:1:1

https://github.com/babashka/babashka.curl#exceptions, I see (:status (ex-data *e) can be used to get the exception data or use {:throw false} to prevent throwing. But those do not seem to work with babashka.curl/request (only with babashka.curl/get, etc.) Can I somehow get the exception data or avoid throwing with babashka.curl/request as well? I prefer using babashka.curl/request because it lets me build up the HTTP request as pure data (maps) in a very ergonomic way prior to actually making the request.

borkdude10:12:54

does it work with get though? I don't think so?

leifericf11:12:12

Ah! I didn't actually check, because the examples in the docs show it like this:

(curl/get "")
;;=> Execution error (ExceptionInfo) at babashka.curl/request (curl.clj:228).
     status 404

(:status (ex-data *e))
;;=> 404

(:status (curl/get "" {:throw false}))
;;=> 404

I presumed it would work with get based on that. But I may have misunderstood the docs.

borkdude11:12:06

the url being an invalid endpoint is a special case which isn't handled as an error while actually processing the request, I think

leifericf11:12:21

Aha, right! Gotcha'

leifericf11:12:43

I suppose I'll stick to http-kit implementation, then! I got that working well, but I wanted to simplify by avoiding async and callbacks.

borkdude11:12:52

borkdude@m1 ~ $ curl foobar
curl: (6) Could not resolve host: foobar
borkdude@m1 ~ $ echo $?
6

borkdude11:12:20

I think it's better to use babashka.http-client than bb.curl btw, bb.curl is kinda deprecated in favor of that

💡 2

borkdude11:12:48

but bb.http-client may have the same problem, which could be fixed potentially if you can make an issue

leifericf11:12:53

Oooh! I was adding http-kit as a dependency myself. I wasn't aware it actually comes bundled with Babashka. Nice!

leifericf11:12:29

I suppose it's this one that corresponds to http-kit.client?

borkdude11:12:08

it corresponds to bb.curl API-wise mostly

👍 2

borkdude11:12:14

but it uses java.net.http

borkdude11:12:18

instead of shelling out to curl

leifericf11:12:50

Nice, thanks! I'll give it a whirl!

leifericf11:12:06

If I can use the HTTP stuff that comes with Babashka, I prefer that over importing another lib.

leifericf11:12:28

The same exception occurs with invalid parameters in the URI when using babashka.http-client. I can create an issue if it's helpful. The exception does not happen with org.httpkit.client (using the same request map), so perhaps that could be a good reference.

borkdude11:12:10

yes, issue welcome

👍 1

borkdude11:12:40

I already knew about this issue and it's disputable what to do here because of how it's handled in Java itself

leifericf11:12:22

Yeah, I see how there are some subjective decisions involved there.

leifericf11:12:09

Interestingly, the status code (404) is included in the exception printed to the console.

borkdude11:12:39

make a proposal in the issue what should be done instead of the current behavior

👍 1

leifericf11:12:15

Also, I want to take a moment to appreciate https://gist.github.com/leifericf/242fb222966c8cfc8beb04539aaf8fab/revisions using Clojure and Babashka. Man, what an excellent language and library.

leifericf11:12:02

The only "breaking change" in the API between http-kit and babashka.http-client was the key :url had to be changed to :uri in the request maps.

👍 2

2023-12-27

Channels