Query fails if one or more cluster nodes do not have records in the set

query = CLIENT.query(NAMESPACE, SET);
    stream = query.foreach();
    /*
        Get list of all avialable keys
    */
    stream.on('error', (error) => {
        throw error;
    });

    stream.on('data', (record) => {
        console.info('data', record);
        console.info('key', record.key.key);
    });

    stream.on('end', () => {
        console.log('done!');
        process.exit(0);
    });

Receiving error - AerospikeError: Record does not exist in database. May be returned by read, or write with policy Aerospike.policy.exists.UPDATE.

error encountered in promise chain => { [AerospikeError: Record does not exist in database. May be returned by read, or write with policy Aerospike.policy.exists.UPDATE]
  name: 'AerospikeError',
  code: 2,
  command:
   QueryCommand {
     client:
      Client {
        domain: null,
        _events: {},
        _eventsCount: 0,
        _maxListeners: undefined,
        config: [Object],
        as_client: AerospikeClient {},
        connected: true,
        captureStackTraces: false },
     args: [ 'sms_data', 'some_set', [Object], undefined ],
     captureStackTraces: false,
     key: undefined,
     stream:
      RecordStream {
        aborted: false,
        client: [Object],
        _events: [Object],
        _eventsCount: 3 } },
  func: 'as_query_parse_records_async',
  file: 'src/main/aerospike/aerospike_query.c',
  line: 237,
  inDoubt: false }

Although the data is present in the namespace and set.

query result :

aql> select * from sms_data.some_set;
+-----------------------------------------------------+----------+
| 0                                                   | name     |
+-----------------------------------------------------+----------+
| MAP('{"dummy":[{"x":"dgjasgdj"}], "name":"Vidur"}') | "Khanna" |
+-----------------------------------------------------+----------+

[jhecking]

This issue is fixed in aerospike@3.3.0.

[jhecking]

The replication factor is set to 2, does that not mean besides the master copy of data on one node, the replica happen on 2 other nodes?

Replication factor 2 means that a copy of the record gets stored on two cluster nodes, i.e. one master copy and one replica.

since the connection is not getting closed by the client I assume, why does it search for .foreach operation on a separate node all together?

For query operations, the client needs to send the request to every node in the cluster since it does not know which node might have records that match the query filter.

The same issue is persisting if I am connecting to one particular node using its IP instead of the cluster’ DNS, how so?

Even if you are just connecting to a single node via it’s IP, the client will find out about the rest of the cluster from this initial seed node and connect to all the cluster nodes.

.get, .exists works just fine shouldn’t that be a problem too or is it an explicit bug fir query.foreach ?

For single-key operations, the client determines which node holds the master copy of that record based on the key digest, and then sends the request to only that particular node.