Key not found

Hi, I am using aerospike in one project, and have lot of sets, so sometimes index is not created. But I get error and everything stops

E, [2019-03-28T14:06:45.294602 #12501] ERROR -- : Key not found
E, [2019-03-28T14:06:45.294686 #12501] ERROR -- : /usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/query/stream_command.rb:48:in `parse_group'
/usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/command/multi_command.rb:48:in `parse_result'
/usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/command/command.rb:403:in `execute'
/usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/client.rb:884:in `execute_command'
/usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/client.rb:729:in `block (2 levels) in query'

Is there a way to get to know what index is missing? Thank you

Can we get a code snippet with this error? What is the expected behavior or outcome you’re looking for? Are you just trying to find the source of the key not found (improved logging) or are you looking for something else?

Hi, thank you for responding. Problem is logging, I am not sure what part of code is responsible for this error, and I would like to know where it was raised and what key is missing.

I think this is just for client health problems: https://www.aerospike.com/docs/client/ruby/usage/logging.html

https://www.aerospike.com/docs/client/ruby/usage/error.html is probably what you want

Yea, I saw that, but result_code only gives me error code, not the cause of the error, in my case what key is missing.

Could you provide a code snippet of showing what the client is doing to get these errors.

I’m not understanding how you don’t already have the key if the client is doing the request. Aerospike doesn’t store the key unless you use the store_key policy, and even then we cannot know the key if the record cannot even be found.

Hi Dorijan,

Is there a way to get to know what index is missing?

If the index was missing, then you would get an “Index not found” error (status code 201).

The “Key not found” error (status code 2) indicates a different error condition. For a query operation, this status code is returned by a cluster node if the set does not exist on that node. On a multi-node cluster, this can occur if the set contains very few records (maybe because it was just created) and one or more cluster nodes do not have any records belonging to that set in the partitions that they are master for.

The client should actually ignore this error rather than raising a client error. (We fixed a similar issue in the Node.js / C client a while ago. Ref. aerospike/aerospike-client-nodejs#253.)

I have filed an issue against the Ruby client here: aerospike/aerospike-client-ruby#77.

Hi, this is example of my code

def get_orders(token, status = 1, makeraddress = '0', _takeraddress = '0')
    return_orders = []
    stmt = Statement.new(Rails.application.config.aerospikeNS, token)
    stmt.filters << Filter.Equal('maker', makeraddress) if makeraddress != '0'
    rs = $client.query(stmt)
    rs.each do |rec|
      if rec.bins['status'] == status
          return_orders << rec.bins['data']
      end
    end
    return_orders
end

and this is the log:

    > D, [2019-03-30T00:35:44.900074 #25720] DEBUG -- : Trying to connect to 127.0.0.1:3000 with 1.0s timeout
    > I, [2019-03-30T00:35:44.900249 #19220]  INFO -- : [cd470eb5-66e4-4a65-8832-9f7c40fe3653] Completed 200 OK in 1ms (Views: 0.1ms | ActiveRecord: 0.0ms)
    > D, [2019-03-30T00:35:36.835928 #25641] DEBUG -- : Node Validator found 1 addresses for host 127.0.0.1:3000: [127.0.0.1:3000]
    > D, [2019-03-30T00:35:36.835968 #25641] DEBUG -- : Trying to connect to 127.0.0.1:3000 with 1.0s timeout
    > D, [2019-03-30T00:35:36.836358 #25641] DEBUG -- : Trying to connect to 127.0.0.1:3000 with 1.0s timeout
    > I, [2019-03-30T00:35:36.836483 #25641]  INFO -- : Node BB9C5A5F2841EA8 peers generation 1 changed
    > I, [2019-03-30T00:35:36.836510 #25641]  INFO -- : Node BB9C5A5F2841EA8 partition generation 0 changed
    > D, [2019-03-30T00:35:36.836536 #25641] DEBUG -- : Update peers for node BB9C5A5F2841EA8
    > I, [2019-03-30T00:35:36.836689 #25641]  INFO -- : Updating partitions for node BB9C5A5F2841EA8 using new protocol
    > I, [2019-03-30T00:35:36.838736 #25641]  INFO -- : Partitions for node BB9C5A5F2841EA8 updated
    > D, [2019-03-30T00:35:36.838794 #25641] DEBUG -- : Cluster config change detected; active nodes: ["BB9C5A5F2841EA8"]
    > D, [2019-03-30T00:35:36.838822 #25641] DEBUG -- : Cluster features: ["peers", "cdt-list", "cdt-map", "cluster-stable", "pipelining", "geo", "float", "batch-index", "replicas", "replicas-all", "replicas-master", "replicas-prole", "udf"]
    > I, [2019-03-30T00:35:36.838849 #25641]  INFO -- : Tend finished. 1 node has joined the cluster. Old node count: 0, New node count: 1
    > I, [2019-03-30T00:35:36.840196 #25641]  INFO -- : New cluster initialized and ready to be used...
    > E, [2019-03-30T00:35:44.900419 #25720] ERROR -- : Key not found
    > E, [2019-03-30T00:35:44.900512 #25720] ERROR -- : /usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/query/stream_command.rb:48:in `parse_group'
    > /usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/command/multi_command.rb:48:in `parse_result'
    > /usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/command/command.rb:403:in `execute'
    > /usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/client.rb:884:in `execute_command'
    > /usr/local/lib/ruby/gems/2.5.0/gems/aerospike-2.9.0/lib/aerospike/client.rb:729:in `block (2 levels) in query'
    > I, [2019-03-30T00:35:44.901132 #25720]  INFO -- : [e6a6b249-26b4-4db6-97b8-827078e172f8] Completed 200 OK in 7ms (Views: 0.1ms)
    > I, [2019-03-30T00:36:02.785502 #25793]  INFO -- : Seeding the cluster. Seeds count: 1
    > D, [2019-03-30T00:36:02.785700 #25793] DEBUG -- : Node Validator found 1 addresses for host 127.0.0.1:3000: [127.0.0.1:3000]
    > D, [2019-03-30T00:36:02.785747 #25793] DEBUG -- : Trying to connect to 127.0.0.1:3000 with 1.0s timeout
    > D, [2019-03-30T00:36:02.786150 #25793] DEBUG -- : Trying to connect to 127.0.0.1:3000 with 1.0s timeout
    > I, [2019-03-30T00:36:02.786381 #25793]  INFO -- : Node BB9C5A5F2841EA8 peers generation 1 changed
    > I, [2019-03-30T00:36:02.786431 #25793]  INFO -- : Node BB9C5A5F2841EA8 partition generation 0 changed
    > D, [2019-03-30T00:36:02.786472 #25793] DEBUG -- : Update peers for node BB9C5A5F2841EA8
    > I, [2019-03-30T00:36:02.786759 #25793]  INFO -- : Updating partitions for node BB9C5A5F2841EA8 using new protocol
    > I, [2019-03-30T00:36:02.789208 #25793]  INFO -- : Partitions for node BB9C5A5F2841EA8 updated
    > D, [2019-03-30T00:36:02.789262 #25793] DEBUG -- : Cluster config change detected; active nodes: ["BB9C5A5F2841EA8"]
    > D, [2019-03-30T00:36:02.789304 #25793] DEBUG -- : Cluster features: ["peers", "cdt-list", "cdt-map", "cluster-stable", "pipelining", "geo", "float", "batch-index", "replicas", "replicas-all", "replicas-master", "replicas-prole", "udf"]
    > I, [2019-03-30T00:36:02.789342 #25793]  INFO -- : Tend finished. 1 node has joined the cluster. Old node count: 0, New node count: 1
    > I, [2019-03-30T00:36:02.790978 #25793]  INFO -- : New cluster initialized and ready to be used...

@Dorijan_Jelincic, what server version are you using? I haven’t been able to reproduce the issue on any 4.x server version. Are you running an older 3.x server by any chance?

My bad, I am able to replicate the error on 4.x as well. It’s just that the error only occurs when you execute a query without filter condition. I.e. makeraddress == '0' in your case. I’ll commit a fix for this issue soon and will release a new client version later today or tomorrow.

Great! thank you!

I’ve just released v2.9.1 of the client to RubyGems.org: aerospike | RubyGems.org | your community gem host

great, thank you, just updated it, and will test it!