seems like it might be

thought doesn’t s/keys* require enought things to make a map?

so technically you’re calling it wit too few args

I think a bare s/keys* is valid just like a bare s/keys is so it should work. > Thus a bare (s/keys) is valid and will check all attributes of a map without checking which keys are required or optional. > keys* has the same syntax and semantics as keys but can be embedded inside a sequential regex structure.

(s/conform (s/or :map (s/keys :req [::x])
                   :opts (s/keys*))
             {::x 1})
  ; [:map #:com.example.playgrounds.spec{:x 1}]
  (s/conform (s/or :map (s/keys :req [::x])
                   :opts (s/keys*))
             [::x 1]))
  ; [:opts #:com.example.playgrounds.spec{:x 1}]

You have a function that says it wants x. and then wants to make a map out of the remaining varargs…thus, don’t t hose remaining args have to be an EVEN number of them? You’re calling it with a single extra arg, which is odd.

You're right, that is odd, but the behaviour with Guardrails is different than without:

(defn with-opts-no-g
  [x & {:as opts}]
  opts)

(comment
  (with-opts-no-g 1) ; nil
  (with-opts-no-g 1 2) ; 2
  (with-opts-no-g 1 2 3) ; {2 3}
  (with-opts-no-g 1 2 3 4))
  ; Execution error (IllegalArgumentException) at com.example.playgrounds.spec/with-opts-no-g (REPL:71).
  ; Don't know how to create ISeq from: java.lang.Long

Not sure if that's worth pursuing as it is misuse in the first place, but the difference between Guardrails and without is something.

the question I have is: does it work right when called right?

that spec just isn’t valid if called with the wrong number of args…and it is probably clojure spec dying on it

if so, then the problem is that GR should try/catch the validation, and report when the validator “crashes”