Add msg to v1 push_status, and say why v2 has no vt_tray

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.
2026-10-15 21:45:38 +00:00
parent 5f46ea166b
commit 83b2617000
2 changed files with 11 additions and 1 deletions
@@ -10,6 +10,11 @@
      "properties": {
        "command": { "const": "push_status" },

+        "msg": {
+          "type": "integer",
+          "description": "Whether this push is the whole object or only what changed: 0 forced/full (what a pushing.pushall triggers), 1 automatic/partial. Confirmed against a real printer. A v1 consumer MUST read this - merging a partial push as if it were full leaves the picture complete, but replacing the cached object with a partial one silently unsets every field the push did not mention. It cannot be inferred any other way, because push_status does not echo sequence_id (see the module description), so there is no correlation back to the pushall that asked for it. v2 sends the whole object every time and this field is informational there."
+        },
+
        "upgrade_state": { "$ref": "../../common/upgrade_state.schema.json" },
        "ipcam": { "$ref": "../../common/ipcam.schema.json" },
        "upload": { "$ref": "../../common/upload.schema.json" },