The note added a moment ago sat inside `properties` as
`"_comment_no_vt_tray": "..."`, which declares a property whose schema is a
string - and in draft 2020-12 a subschema has to be an object or a boolean.
It parses as JSON and reads fine, and a strict validator would reject the
whole schema. `$comment` is the keyword for this and belongs beside
`properties` rather than inside it.
Swept the rest of schemas/ for the same shape while here: every other
property value is a real subschema.
Two things the live captures showed that the schemas did not say.
`msg` was missing from the v1 push_status schema, which is the one version
where it is load-bearing. v1 pushes only the fields that changed, except for
a pushall-triggered push which is the whole object, and `msg` is how a v1
message self-describes which it is (0 forced/full, 1 automatic/partial). A
consumer that replaces its cached object with a partial push silently unsets
every field that push did not mention, and there is no other way to tell:
push_status does not echo `sequence_id`, so there is no correlation back to
the pushall that asked for it. continuum-proxy has read this field since the
cache was written; the schema just never declared it.
v2 had it with no description. It is informational there - v2 sends the whole
object every time - so it now points at the v1 note rather than repeating it.
The other half is an absence, which a schema cannot express by staying
silent: v2 has no `vt_tray` because a real v2 printer omits the key entirely
rather than sending an empty object. That is recorded as a comment so nobody
adds it for symmetry with v1, because the distinction is the thing: absence
means "not reported", not "no external spool", and it is exactly why
`EXTERNAL_SPOOLS` in continuum-proxy is a constant instead of being counted
from a report.
octoturge