# Check KAPI state

## Check logs

* Check locator, SR contract address, fetching modules from SR, type of module and id

2023-04-04 13:35:22	
{"context":[[1,"0x9D4AF1Ee19Dad8857db3a45B0374c81c8A1C6320",500,500,10000,0,"curated-onchain-v1",{"hex":"0x642b7c30","type":"BigNumber"},{"hex":"0x85d0ad","type":"BigNumber"},{"hex":"0x1a","type":"BigNumber"}]],"level":"info","message":"Modules:"}
2023-04-04 13:35:22	
{"level":"info","message":"Fetched 1 modules"}
2023-04-04 13:35:21	
{"context":"0xa3Dbd317E53D363176359E10948BA0b1c0A4c820","level":"info","message":"Staking router module address"}
2023-04-04 13:35:21	
{"context":"0x1eDf09b5023DC86737b59dE68a8130De878984f5","level":"info","message":"Contract locator address: "}

Compare staking module address with address in registry library

Staking module list we use for `/v1/modules` endpoints.
and to fetch data by module `id` / `address`.

* Check modules list contains module that was fetched above

curl -X 'GET' \
  'http://localhost:3000/v1/modules' \
  -H 'accept: application/json'

* Check status

curl -X 'GET' \
  'http://localhost:3000/v1/status' \
  -H 'accept: application/json'

El meta should newer or equal to CL meta

2023-04-04 13:35:22	
{"context":{"name":"Update Staking Router Modules keys"},"level":"info","message":"Job ended"}
2023-04-04 13:35:22	
{"level":"info","message":"Curated Module metrics updated"}
2023-04-04 13:35:22	
{"context":{"currMeta":{"blockHash":"0x55db546f426bfbbad6f81272ebca4454a4a7ba7c3951b1993492d30fe26be68d","blockNumber":8771695,"keysOpIndex":1766,"timestamp":1680600912},"prevMeta":{"blockHash":"0x55db546f426bfbbad6f81272ebca4454a4a7ba7c3951b1993492d30fe26be68d","blockNumber":8771695,"keysOpIndex":1766,"timestamp":1680600912}},"level":"info","message":"Collected metadata"}
2023-04-04 13:35:22	
{"level":"info","message":"Start updating curated keys"}
2023-04-04 13:35:21	
{"context":{"name":"Update Staking Router Modules keys"},"level":"info","message":"Job started"}

if it is not, we should check job that update keys. Lets find start and end of job. If logs are actual and contain records it means keys update job works properly.

If job was launched recently, maybe EL CL not are not sync yet.

* check keys endpoint

curl -X 'GET' \
  'http://localhost:3000/v1/keys' \
  -H 'accept: application/json'

check meta is actual, check keys

here we can go to NOR contract and compare keys for the same hash, compare true false amount of keys

we also can compare true/false amount of keys with values in contract using metric `lido_keys_api_keys_by_sr_module_and_operator metric`.

* check validators job

2023-04-04 13:35:21	
{"context":{"name":"Update validators from ValidatorsRegistry"},"level":"info","message":"Job ended"}
2023-04-04 13:35:21	
{"level":"info","message":"ValidatorsRegistry metrics updated"}
2023-04-04 13:35:21	
{"context":{"name":"Update validators from ValidatorsRegistry"},"level":"info","message":"Job started"}
2023-04-04 13:35:21	
{"context":{"cronTime":"*/10 * * * * *","name":"ValidatorsUpdateService"},"level":"info","message":"Cron job cycle start"}

* check validators endpoint

curl -X 'GET' \
  'http://localhost:3000/v1/modules/1/validators/validator-exits-to-prepare/1?percent=10' \
  -H 'accept: application/json'

if it returns result, EL has actual data.
Here we can check id of keys and compare manually with data in contract.

## Run manual tests