In mqtt_schema_parse (schema.c), the type checking logic only accepts string values (placeholders or fixed text) and nested objects. Any array value inside an object is rejected, causing the entire validation to fail with -1.
This limitation makes it impossible to include static JSON arrays in a message template. For example, the following schema is perfectly valid JSON and is intended to produce a fixed array in the final MQTT payload, but it fails validation:
Expected Behavior
Support arrays as literal values: the entire array should be output as-is in the final JSON message.
If not supported, at least provide clear error feedback (e.g., log or specific return code) indicating which field and type caused the failure.
Steps to Reproduce
Call mqtt_schema_validate with the above JSON string. The function returns -1, but without any specific error message.
{
"services": ["service1", "service2", "service3"]
}
When mqtt_schema_validate processes this input, it iterates over the root object, sees that the value of "services" is an array, and since json_is_string() is false and json_is_object() is also false, it jumps to the final else and returns -1. The user receives no specific error message indicating why the schema was rejected.
Expected Behavior
Arrays should be supported as literal values in templates. When an array is encountered, it should be treated as a fixed JSON array and later serialized as‑is during encoding. This would allow users to include static lists, nested structures, or configuration arrays without forcing them to convert everything to placeholder strings or flatten the structure.
Steps to Reproduce
Call mqtt_schema_validate with the following JSON string:
{"services": ["a", "b", "c"]}
Observe that the function returns -1 (failure).
Relevant Code
if (json_is_string(value)) {
// ...
} else if (json_is_object(value)) {
// ...
} else {
return -1; // arrays (and other types) end here
}
Suggested Improvement
Add a branch for json_is_array(value) in the else if chain, and mark the field with a new type (e.g., MQTT_SCHEMA_LITERAL_ARRAY) that will copy the entire JSON array unchanged during encoding. If full support is not feasible immediately, at least provide a clear error log indicating that array values are not supported, rather than a silent -1.
In mqtt_schema_parse (schema.c), the type checking logic only accepts string values (placeholders or fixed text) and nested objects. Any array value inside an object is rejected, causing the entire validation to fail with -1.
This limitation makes it impossible to include static JSON arrays in a message template. For example, the following schema is perfectly valid JSON and is intended to produce a fixed array in the final MQTT payload, but it fails validation:
Expected Behavior
Support arrays as literal values: the entire array should be output as-is in the final JSON message.
If not supported, at least provide clear error feedback (e.g., log or specific return code) indicating which field and type caused the failure.
Steps to Reproduce
Call mqtt_schema_validate with the above JSON string. The function returns -1, but without any specific error message.
{
"services": ["service1", "service2", "service3"]
}
When mqtt_schema_validate processes this input, it iterates over the root object, sees that the value of "services" is an array, and since json_is_string() is false and json_is_object() is also false, it jumps to the final else and returns -1. The user receives no specific error message indicating why the schema was rejected.
Expected Behavior
Arrays should be supported as literal values in templates. When an array is encountered, it should be treated as a fixed JSON array and later serialized as‑is during encoding. This would allow users to include static lists, nested structures, or configuration arrays without forcing them to convert everything to placeholder strings or flatten the structure.
Steps to Reproduce
Call mqtt_schema_validate with the following JSON string:
{"services": ["a", "b", "c"]}
Observe that the function returns -1 (failure).
Relevant Code
if (json_is_string(value)) {
// ...
} else if (json_is_object(value)) {
// ...
} else {
return -1; // arrays (and other types) end here
}
Suggested Improvement
Add a branch for json_is_array(value) in the else if chain, and mark the field with a new type (e.g., MQTT_SCHEMA_LITERAL_ARRAY) that will copy the entire JSON array unchanged during encoding. If full support is not feasible immediately, at least provide a clear error log indicating that array values are not supported, rather than a silent -1.