client.keyStates().query() does not work without sn

[nkongsuwan]

I am not sure if this is a feature or a bug. Currently, client.keyStates().query(prefix, sn) does not work if a sequence number sn is not specified.

In Signify-TS, sn is optional, so I expect that a client should be able to query for the entire KEL of an AID without specifying a sequence number for a particular key event.

[lenkan]

Just as a recap of the short discussion in meeting: It would be useful to be able to query for the latest key state of an AID, without knowing the sequence number.

[2byrds]

From the dev meeting:
More detail in the issue would be helpful. Enpoint handler query for instance doesn't require SN.

[nkongsuwan]

I came across this problem when I was trying to do multisig delegated inception. I found that the delegatee needs to specify the precise sequence number of the delegating interaction event at which the delegatee's inception is anchored. Otherwise, the controllers of the delegatee could not find the interaction event and finish the waitOperation.

See:
https://github.com/WebOfTrust/signify-ts/blob/main/examples/integration-scripts/multisig-vlei-issuance.test.ts#L375

[iFergal]

The problem here appears to be with keripy and not KERIA.

sn causes KERIA to send /logs request, which will cause agents/witnesses to stream the KEL (each event in one message) to the caller. So the CESR parser parses individual events, which updates the kevers.

Without sn, it sends /ksn (key state notice) to get the latest state. There are two issues:

1. processReplyKeyStateNotice is called when receiving the /ksn reply, but I don't think it does anything to update the kevers. I need to take a closer look but from what I can see it's just updating the tracking of queries and replies after validating the ksn with BADA.
2. The long running op in KERIA for this will (at least on my machine) never complete even if the kevers are updated. A keyStateSaved event gets pushed on the kevery cues - but there are multiple Doers iterating to pull off cues - Respondant.cueDo seems to pull it off quicker on my machine and do nothing with it. Not sure what the HIO strategy is for this - we can re queue it but presume it would be better to only have one Doer processing cues.

[SmithSamuelM]

ksn is a notice of key state. Its up to the recipient of a ksn to decide to request an update key state via a replay of missing Key events. I don't think that logic to decide to request an update to key state in response to a KSN was ever implemented. But I could be wrong.

[iFergal]

Got it, that makes sense! I took another look and I can see that the LogQuerier Doer that's created by the KeyStateNotifier will do what you describe automatically with the sequence number from the ksn reply. So number 1 isn't an issue.

The issue then I think seems to be number 2 in my list where the KeyStateNotifier cannot grab the ksn event off of cues fast enough before another Doer takes it, so the LogQuerier is never created.