Validation
By default, Graph queries are validated strictly: any problem — an unknown field, an unknown navigation edge, an invalid filter — fails the request with a 400 error. This is usually what you want for queries authored in code, since problems surface immediately.
When queries are composed by users, however, strict validation can be hostile. A saved query that references a field which has since been removed from the model would fail entirely, even though the rest of the query is perfectly fine.
For those scenarios, the Graph endpoint accepts a validation query parameter:
POST /resources/graph?validation=warnIn warn mode, the query is sanitized: invalid parts are removed or neutralized, the sanitized query is executed, and all discovered problems are returned as warnings alongside the result.
Modes
| Mode | Behavior |
|---|---|
strict (default) | The first validation problem fails the request with 400 and an error body. |
warn | Invalid parts are repaired (see below), the query executes, and problems are returned as warnings. |
Warn-mode repairs
| Problem | Repair | Warning code |
|---|---|---|
Unknown field in node.fields | Field is dropped (warning keeps the "Did you mean 'x'?" suggestion) | INVALID_FIELD |
Unknown edge in node.navigate with require='any' (default) | Sub-navigation including its subtree is dropped | INVALID_EDGE |
Unknown edge in node.navigate with require='some' or 'none' | Sub-navigation is dropped and the parent matches nothing — an unevaluable gate never widens the result | INVALID_EDGE |
Invalid filter | Filter is replaced by a constant-false predicate — it matches nothing | INVALID_FILTER |
Invalid orderBy | orderBy is cleared (result is unordered) | INVALID_ORDER_BY |
phrase longer than 100 characters | phrase is cleared | INVALID_PHRASE |
Options not allowed with require='none' | Offending options are cleared | INVALID_OPTION |
Unknown root edge | No query is executed; the result is empty (nodes: []) | INVALID_EDGE |
Invalid filters match nothing
Dropping an invalid filter would return more data than requested, which could be dangerous. A filter that cannot be understood therefore behaves as if it matched nothing.
Response shape
Warnings are returned per query, nested inside that query's result object. The warnings key is only present when warnings exist:
{
"orders": {
"nodes": [],
"warnings": [
{ "code": "INVALID_FIELD", "message": "Field 'nam' not recognized. Did you mean name?" }
]
}
}- JsonTable format (
?format=jsontable): warnings are available on the optionalwarningsproperty of the table object. - CSV format: warnings are returned in the
X-Query-Warningsresponse header as a JSON array.
Scope
The validation mode only applies to the Graph HTTP endpoint. Filtrera query usage in components (rules, reactors, jobs) is always strict, as are actor query messages and live queries.