Closed quinkennedy closed 8 years ago
Overall looks good to me! Just to confirm, we're not forcing 'value' to conform to any type?
My only other comment was to add a 'catch' for JSON.parse so we can log that error.
I see it in the fold! Merge it!
for the "value" parameter, I don't provide any specifics, so it should match anything (number, string, boolean, object...)
I have only tested against a couple clients (boolean, string) and hand-crafted bad config messages. I guess until we get a testing harness integrated (WIP on https://github.com/quinkennedy/spacebrew/tree/test-driven) going live is our best test :fearful:
PR looks good to me with the new fix. We could: a) merge this into master and test on sandbox b) merge into a branch and test on sandbox
I say we go wild and do a), but up to you
Logging into sandbox right now to test.
addresses #70 and probably many other latent errors that may arise from malformed JSON.
The schema definition is somewhat relaxed since it does not specify
"additionalProperties":false
anywhere, which would further restrict what comes in. I focused on specifying required and common properties.I don't think I'm missing anything, so I am open to adding
"additionalProperties":false
to everything except forvalue
(in messages) and possiblyoptions
objects (in client config).