Fork me on GitHub
#ring-swagger
<
2017-11-15
>
slipset09:11:42

A little bit on error messages:

slipset09:11:13

I was playing around with specs on path-params, and I thought the :- thingy was schema-only, so I made my thing like this

slipset09:11:25

(context "/product/:id" []
          :coercion :spec
          :path-params [id ::id])

slipset09:11:13

The error I get is either

slipset09:11:15

CompilerException java.lang.ClassCastException: clojure.lang.Keyword cannot be cast to clojure.lang.IObj, compiling:(/Users/erik/Documents/telenordigital.com/di-data-inventory/src/data_inventory/handler.clj:225:9) 

slipset09:11:48

when I only evaluate this form, or

slipset09:11:58

CompilerException java.lang.ClassCastException, compiling:(/Users/erik/Documents/telenordigital.com/di-data-inventory/src/data_inventory/handler.clj:225:9)

slipset09:11:04

if I evaluate the whole api.

slipset09:11:55

I appreciate the fact that it might be hard getting good/descriptive error messages here, but I thought I’d post this as a bit of inspiration.

slipset09:11:07

As always, thanks for the great work!

slipset13:11:57

Also, when using :spec coercion, swagger fails with

slipset13:11:59

500 : {"type":"unknown-exception","class":"java.lang.Exception"} 

slipset13:11:09

when at least one spec is missing.

slipset13:11:14

so given something like

slipset13:11:41

(s/def ::foo (s/keys :req-un [::bar]))

slipset13:11:59

where ::bar is not defined, swagger shows nothing at all.

slipset13:11:17

just the exeption (which in the logs tells me that no spec is found for ::bar

slipset13:11:32

This is somewhat unfortunate, as it makes gradual typing hard.

slipset13:11:03

This may or may not be a design choice 🙂

ikitommi13:11:17

There was just today a discussion about this in the Clojure Google Group: https://groups.google.com/forum/m/#!topic/clojure/i8Rz-AnCoa8

ikitommi13:11:22

I think both could be “fixed” on c-api side: 1) validate the plumbing.core/letk syntax for bad syntax 2) validate that all s/keys specs are fully set and fail nicely

ikitommi13:11:23

could you write issues of these? and if you have time to fix ’em too, PRs welcome 🙂

ikitommi13:11:04

and, actually, that swagger-gen should fail-early on the spec-tools.

ikitommi13:11:08

should be easy to catch..

slipset13:11:14

I’ll make issues for them for sure, compojure-api project?

ikitommi13:11:31

1 to c-api, 2 to spec-tools, thanks!

slipset13:11:00

Also, I hope this is the correct place to discuss these kinds of things?

ikitommi13:11:32

yes, definetely

slipset14:11:34

Hmm, Still some problems 😞

slipset14:11:06

So, in a nested context, where the outer context has default coercion, I have the following:

slipset14:11:48

(context "/product/:id" []
          :coercion :spec
          :path-params [id :- ::id]
          (GET "/foo" []
            :return boolean?
            :summary "foo"
            (ok (reports/foo 1))))

slipset14:11:17

and ::id is defined as (spec/def ::id pos-int?)

slipset14:11:42

This shows up fine in swagger, but when I press “try it out” i get the following stack-trace:

slipset14:11:16

2017-11-15 14:14:47,930 [worker-4] ERROR compojure.api.exception - No implementation of method: :spec of protocol: #'schema.core/Schema found for class: clojure.lang.Keyword 
java.lang.IllegalArgumentException: No implementation of method: :spec of protocol: #'schema.core/Schema found for class: clojure.lang.Keyword
	at clojure.core$_cache_protocol_fn.invokeStatic(core_deftype.clj:583)
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:575)
	at schema.core$eval7391$fn__7403$G__7380__7408.invoke(core.clj:110)
	at schema.coerce$eval8639$coercer__8644$fn__8645$fn__8646.invoke(coerce.clj:32)
	at schema.spec.core$sub_checker$fn__7162.invoke(core.clj:92)

ikitommi14:11:34

I’ll take a look on that later today

mhcat17:11:45

hey all - I have a question about using middleware to transform responses. I have code I want to apply to the response generated by all my handler functions, which brings the response into conformance with the schemas I've defined for them via compojure-api. It seems that the schema validation is happening before any of the middleware gets the response. Am I missing some way to configure middleware, or must I guarantee that anything returned by a handler is in the correct form?

mhcat17:11:40

my current workaround is a defhandler macro which adds the transformation step to the end of all my handler functions. That's a little gruesome though.

slipset20:11:00

Ok, so a smaller repro here:

slipset20:11:25

(context "/spec-test/:id" []
        :coercion :spec
        :path-params [id :- ::id]
        (GET "/foo/" []
          :return any?
          (ok {:id 1 :name "foo" :date (DateTime.)})))

slipset20:11:51

(context "/spec-test" []
        :coercion :spec

        (GET "/:id/foo/" []
          :path-params [id :- ::id]
          :return any?
          (ok {:id 1 :name "foo" :date (DateTime.)})))

slipset20:11:53

works fine

slipset20:11:13

(context "/spec-test/:id" []
        :coercion :spec

        (GET "/foo/" []
          :path-params [id :- ::id]
          :return any?
          (ok {:id 1 :name "foo" :date (DateTime.)})))

slipset20:11:25

seems to work as well, which is a workaround I can live with...

slipset20:11:28

If you tell me which project this relates to, I'll be more than happy to file another issue 🙂

slipset22:11:32

Another one

slipset22:11:37

"pred": "clojure.lang.LazySeq@ba0ee888",

slipset22:11:10

Should probably do a doall or smthing to realize the lazy-sql which is the pred?