Search code examples
node.jsclientaerospike

Aerospike Query Error


    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" |
+-----------------------------------------------------+----------+

Solution

  • This is a bug in the Aerospike Node.js client (all versions up to and including v3.2.0). The short version is, that this occurs on Query operations, if at least one server node in the cluster does not have any records in the set that you are querying. See issue #253 on GitHub for details. This should get resolved in the next client release.