Rudder

Also, the inconsistent state is only kept when adding exactly the same criteria, e.g. Hostname =, then clicking on + adding a Hostname = again.
When changing = to ≠, or Hostname to something else, the button is grayed out so this error cannot be obtained.

So, the actual use case where the error is likely to happen is when having a OR operand, in which case different @Hostname =" make sense (but an empty one still does not)

the same update error also happens when the updating the group via API : when updating with a payload

{
  "query": {
    "select": "nodeAndPolicyServer",
    "composition": "And",
    "where": [
      {
        "objectType": "node",
        "attribute": "nodeHostname",
        "comparator": "eq",
        "value": "" 
      }
    ]
  }
}

the API returns the same error as above, but at the same time the group is still updated with the new invalid query, which is very surprising !

When updating again the group with the same payload, the response is idempotent : it's the group with the updated query. But then when getting the group with the GET endpoint, the query is simply empty (it is analogous to the empty list of criteria in the UI).
So there are several problem :

• the group is still updated despite the response of the API being an error : the validation is not strict when writing
• reading back the group from LDAP does additional on the value, depending on the comparator, but we don't need this validation when reading