You're only reading the last part of the failure -- the first part says "2018-09-26T21:47:57.304Z" fails spec: :io.cloudrepo.signup.email/creation-timestamp

So you have an ::email/creation-timestamp spec and that string fails to conform to it.

Since that fails, the whole :success part fails and the the whole hashmap fails the :not-found part -- the val in explain is the whole hash map, not just the creation timestamp string.

s/keys will conform/validate any keys that are provided that have a corresponding spec, not just the listed :req keys.

^ @chris547

Ah, that makes sense now

I didn't even check to see if the timestamp was okay because I didn't care about it

but I guess that's good because it will catch where you create bad data at the first possible point

rather than when you explicitly check, right?

Yup. The assumption is that specs should apply wherever those uniquely-name keys appear.

If you're using unqualified keys, you won't run into that -- since only the :req-un and :opt-un keys will map to specs.

Okay, thanks Sean - you're always super helpful!

I have this spec:

(spec/cat :op #{:jdbc/insert}
            :table keyword?
            :row map?)

:options (s/? ::opt-spec)

(assuming you wanted to optionally pass in an options map of some sort @lilactown)