Troubleshooting
The problems a rule file can have, and how to fix them.
A rule file with any problem is not loaded at all: it never becomes a rule that silently reports nothing. The panel lists it above the rules, in the Rules settings, with each problem. The other rules still run.
Every problem names the file and the JSON path of the faulty value, such as checks[0].condition.field.
| Kind | Example | Fix |
|---|---|---|
| JSON | Invalid JSON: Expected double-quoted property name in JSON at position 22 | The file is not valid JSON. Look for a trailing comma or a missing quote. |
| Shape | severity: Must be one of: "info", "warning", "error". | A property has the wrong type, a value not allowed, or an unknown name. |
| Definition | checks[0].condition.field: Unknown field "clip.scal". Fields of scope "clip" start with "clip.", "track.", "sequence.", "options." | A field, an operator on the wrong type, a placeholder or a regular expression is wrong. |
| Duplicate | id: Duplicate rule id "my-rule": already defined by … | Two of your files use the same id. Rename one. |
Common mistakes
- An unknown property. Every property name is checked, so a typo (
"serverity") is an error rather than a setting silently ignored. - A field from another scope. A
trackrule cannot readclip.*. The fields reference lists the scopes of each field. - Comparing types that differ.
greaterThanneeds a number field and a number value. Options compared with a field must have the field's type. - A string where a number is expected.
"value": "120"is a string; write120. - A backslash in a regular expression. JSON strings escape backslashes:
\dis written"\\d". - A rule that never reports. Check for unknown values: a comparison on an unknown value is false.
Using a built-in id
A custom file reusing the id of a built-in rule is not an error: it replaces the built-in rule.