Is there a quick way to diagnose schema failures? Dump them to a log or something? I’m running an external test against a yada server, it’s failing because something they send me doesn’t match my schema, but I’m not sure what.

I know there are errors sent back to the caller in the http response body, but I don’t have an easy way to see that.

@korny Hmm, doesn’t Yada send an {:errors …} thingie back, like compojure-api?

It probably does somewhere, but that’s all in magic code inside my {:methods {:post {:parameters {:body my-schema} … } } resource - I guess I’m not sure where to hook in error checking myself. Anyway I’m going to leave it until after work, will give it a better look then

Actually I’m also tempted to follow Postel’s law, and just get rid of the schema check entirely. It’s nice as a proof of concept to say “hey, we can check schemas” but TBH I’m not keen on writing code which type checks incoming data too rigorously.

@korny schema checks get more useful the bigger your api gets - we have shared client/server schema and it's brilliant for flushing out bugs after api changes (not as good as static checks, but pretty good for clojureland), particularly in development. it's a bit more ambiguous in production, since it can make older clients unnecessarily incompatible with newer servers

I have an async question. Consider the following async endpoint:

;; [aleph.http :as http]
;; [manifold.deferred :as d]

["/async"
         (yada/resource
          {:produces "application/json"
           :methods
           {:get
            {:response (fn [ctx]
                         (d/chain (http/get "")
                                  (fn [resp]
                                    {:result (slurp (:body resp))})))}}})]

That Thread/sleep probably locks up the thread pool.

hmm - that shouldn't affect static resources served by yada though, since it's the threadpool of a separate process

Hmm. This is odd

Your expectation is correct

Do you get comparable behaviour with something like (future (Thread/sleep 5000))?

I'm wondering if Thread/sleep is locking up the general aleph threadpool?

But it's a separate proc

@dominicm The Thead/sleep is in a different process. From the perspective of Yada this is just IO

Oh, I see. I wasn't paying enough attention 😁

@malcolmsparks Do you want me to wrap this into an example project, so you can run it?

What versions of yada/manifold/aleph? I'd like to replicate tonight

Yes please

(Terrible internet here)

@malcolmsparks Reproduced the issue here: https://github.com/borkdude/yada-async-test/tree/master

@borkdude there's a max concurrent number of requests to the same domain in browsers, your README says you run the test from the same browser (tho different tabs). I think you hit a browser limitation and not a yada bug

Try the 20 request to /api/async with apache bench or something instead of from a browser

@thegeez ah, thanks, I’ll try

ab -n 20 -c 20 -v 10 -H 'Accept: application/json' ''

ab -n 20 -c 20 -v 999 -H 'Accept: text/plain' ''

Yup, that’s it. Thanks @thegeez !

@malcolmsparks So, mystery solved

😆 That's great

https://twitter.com/oss_clj/status/848897738536308736

Apparently 1 tweet gets you on there 😛

Nice detective work!