There is brief description of the what the QUERY NODE is just below the table in the docs page. Here is some more detail.
Data in aerospike is stored in 4096 partition and data is stored and moved around in units of partition. Given row/record falls in one such partition based on static hash. In any given particular cluster state a node is designated MASTER or REPLICA. When cluster activity happens (node up/down with data in it while writes are going on), there can be many different versions of same partitions present in cluster. In such case when trying to fetch data for a certain partition while performing secondary index query, there are two options
To bring data from all the copies of a partition in cluster and remove duplicate rows and return unique rows only. This can either be done at one of the server nodes or at the client. Both of which is not scalable in nature because it either introduces huge intra-cluster traffic or can flood client with lot of data.
Just INDEPENDENTLY decide at each node whether to return result back for a certain partition without communicating with any other node in cluster.
We pick the second option above. A secondary index query is sent to all the nodes in the cluster. And each node decide INDEPENDENTLY on whether it should be returning a value for all the row in a given partition or not. For a given partition at any point there is only one such node in cluster. This node is what is referred to as QUERY NODE.
Under normal running cluster MASTER is also the QUERY NODE. But in presence of multiple copies one of nodes other than MASTER can be picked up as QUERY NODE. A node is picked based on function of number of row in partition and position in the succession list. A node having higher number of rows is picked with weightage MASTER > REPLICA > node outside replica list. When the cluster settles and migration finishes MASTER becomes the QNODE again.
Given the async nature of when a QUERY NODE designation changes from MASTER to non-MASTER and back again, it is possible that a when a query is received for a certain instanct none of the node may be see itself as QUERY NODE for a particular partition hence not return result for it. This can happen for brief moment of when query is performed.
The case you are describing though there is only 1 copy of partition there is still a transition happening wherein a new node which is MASTER for a certain partition becomes QUERY NODE post migration. If query hits server when this transition is happening it may not see all the data. With small number of rows many such transition can happen in rapid succession and show up much more pronounced. But when there are large number records such transition are spaced out in timescale.