hmm, this leads me to the realization of a bug. But fixing this bug is problematic.
Ideally the fix would be to make the input require an array, but this cannot be forced through the schema or else it would require you to always use the in filter when you might want to instead use the eq filter. This should be fixed on Dgraph side to silently ignore this filter when the object is nil.
Here is another thing to try in the meantime.
type Delta @auth(
query: {rule: """query ($NAMES: [String]!) {
queryDelta(filter: {mode: {eq: Public}, or:{name: {in: $NAMES}}}) { id }
}""" }
){
id: ID!
name: String! @search(by: [hash])
mode: DeltaMode! @search
}
Notice the ! after [String] this might silent the query when the rule is not met, but this might also stop the whole auth query from running, if so then this may also work:
type Delta @auth(
query: { or:[
{ rule: "query { queryDelta(filter: {mode: {eq: Public}}) { id }}" },
{ rule: "query ($NAMES: [String]!) { queryDelta(filter: {name: {in: $NAMES}}) { id }}" }
]}
){
id: ID!
name: String! @search(by: [hash])
mode: DeltaMode! @search
}
Which hopefully in theory would silently error on the second rule, but still process the first rule.
Note: There is no way to logically say in an input that there has to be at least one value in a list. The [String!]! signifies that there has to be a list and the items in the list cannot be nil, but the list itself could be empty.