Problem
In pkg/constraints, a constraint value beginning with a bare ! token (e.g. value: "!some-label-key") on an ordinary scalar constraint parses cleanly as OperatorExact with the literal value "!some-label-key" — an exact string match that can never match any reading. The constraint silently never passes (or, for a negative-testing author expecting negation semantics, silently never expresses what they meant), with no parse error.
!= exists as a real operator prefix (value: "!= foo"), so a !-prefixed bare token is plausibly an author's attempt at negation and is always a mistake — but today it fails silently rather than loudly.
Context
Found while implementing the node-set constraint form for #1755 (PR #2000), whose value grammar legitimately uses !<label-key> for its negated predicate — but only under the name-dispatched NodeTopology.gpu-nodes.label form. The scalar path's acceptance of the same shape as an exact match invites confusion between the two grammars.
Proposed fix
In ParseConstraintExpression, reject a value matching ^!\S that is not != with ErrCodeInvalidRequest ("did you mean !=, or the node-set form?"), or at minimum log a warning. Fail-closed is the right direction: a constraint that can never match is a validation gate that never gates.
Scope note
Deliberately excluded from PR #2000 (pre-existing behavior, not introduced there) per the bounded-scope rule.
Problem
In
pkg/constraints, a constraint value beginning with a bare!token (e.g.value: "!some-label-key") on an ordinary scalar constraint parses cleanly asOperatorExactwith the literal value"!some-label-key"— an exact string match that can never match any reading. The constraint silently never passes (or, for a negative-testing author expecting negation semantics, silently never expresses what they meant), with no parse error.!=exists as a real operator prefix (value: "!= foo"), so a!-prefixed bare token is plausibly an author's attempt at negation and is always a mistake — but today it fails silently rather than loudly.Context
Found while implementing the node-set constraint form for #1755 (PR #2000), whose value grammar legitimately uses
!<label-key>for its negated predicate — but only under the name-dispatchedNodeTopology.gpu-nodes.labelform. The scalar path's acceptance of the same shape as an exact match invites confusion between the two grammars.Proposed fix
In
ParseConstraintExpression, reject a value matching^!\Sthat is not!=withErrCodeInvalidRequest("did you mean!=, or the node-set form?"), or at minimum log a warning. Fail-closed is the right direction: a constraint that can never match is a validation gate that never gates.Scope note
Deliberately excluded from PR #2000 (pre-existing behavior, not introduced there) per the bounded-scope rule.