Closed lenkan closed 3 weeks ago
From our keri dev meeting: Perhaps related to the change in order of the receipts? Works on .1.3 docker image @rodolfomiranda says Provenant has seen similar but more investigation is needed. All the PRs in signify-ts are left hanging until this is resolved. Stable versions are okay, this is a problem from main.
I recreated the issue in my dev environment and walked through it with the debugger.
The reason that the response doesn't contain the event information (we expect an 'i' field in the response, that comes from the key state notice) is because the cid isn't in the kever list and so the oobi response won't contain the key state information:
And so during the contact creation/resolution the oobi is successfully retrieved
So far I believe the issue occurs during the parsing of the dip event, it is escrowed as a msifit as the delpre is consider non-local (i'm looking into what that means):
Noting some potentially helpful activity regarding delegation/non-local/misfit info: https://github.com/WebOfTrust/keripy/pull/680 https://github.com/WebOfTrust/keripy/pull/674
Confirmed that the delegator is escrowing the dip event as a Misfit as part of the delegation approval/anchoring exchange.
It seems the escrow of the misfit dip key event prevents the contact from being created and so the oobi cid doesn't retrieve the key state for the delegate.
I checked to see if any Keripy tests exercise the exception and none seem to trigger a non-local delegation scenario. I commented out the exception and all tests pass and so does the delegation contact retrieval. I'm not sure yet how to modify the test or keripy eventing logic to provide the local/non-local protections that were intended while at the same time allowing the integration test to complete the full flow.
Interestingly the dip is received by the deleGATOR automatically on creation of the deleGATE identifier. I asked about it on discord and got some additional information to consider regarding delegation/witness thresholding: https://discord.com/channels/1148629222647148624/1148734044545228831/1241198502298517564
deleGATE keria agent Anchorer (in delegating) sends the msg https://github.com/WebOfTrust/keria/blob/5bdc47394cc0a3d5458c7c0cd4dac3abe072e939/src/keria/app/delegating.py#L66 I'll look to see how the misfit escrow is processed. It looks like there should be a 'promotion' process that should lead to misfit escrow processing, which i'm guessing is currently broken.
Some hints here
Phil is making some changes to keripy for delegation. There will also be changes to KERIA https://discord.com/channels/1148629222647148624/1148734044545228831/1241438394207309844
Phil is making some changes to keripy for delegation. There will also be changes to KERIA https://discord.com/channels/1148629222647148624/1148734044545228831/1241438394207309844
Phil has merged Keripy delegation fixes to reverse the order to check witness receipts and then check delegation approval. As well as some additional changes https://github.com/WebOfTrust/keripy/pull/784/files
Phils changes allowed us to progress past the Misfit exception. But the delegation fails in the same way, this time it appears the delegation escrow isn't being processed once the delegation was confirmed with an ixn. More infor here https://discord.com/channels/1148629222647148624/1148734044545228831/1241881199102922752
Good discussions this morning with Phil to identify the ideal fix. We are also discussing it in the community meeting today. https://discord.com/channels/1148629222647148624/1148734044545228831/1242475776813830234
@pfeairheller is going to work on a delegable processor for KERIA and submit a PR
Summary of changes that are being tested/reviewed: https://github.com/WebOfTrust/keria/issues/230 is wrapping up. @pfeairheller updated KERIpy to run parsing locally and provide a delegation escrow processor https://github.com/WebOfTrust/keripy/pull/786/files @pfeairheller update KERIA agents to leverage the newly available delegation escrow https://github.com/WebOfTrust/keria/pull/246 @2byrds made a complimentary PR to allow the user to approve the delegation after the interaction seal has been added to the KEL and successfully ran the test that @lenkan created as part of issue 230 https://github.com/WebOfTrust/keria/pull/247/files
KERIA PR submitted but it's failing on a KERIpy error https://github.com/WebOfTrust/keria/pull/248 I have submitted an issue/fix for KERIpy so the KERIA PR will pass the testing. https://github.com/WebOfTrust/keripy/pull/789
Delegator test is fixed by https://github.com/WebOfTrust/keria/pull/250 Multisig-delegation test currently works because the only the delegatee is multi-sig but i'm upgrading it to make both sides multisig as part of https://github.com/WebOfTrust/keria/issues/249 because multisig-vlei-issuance fails with a multisig delegator
See initial draft PR here: https://github.com/WebOfTrust/signify-ts/pull/252, which is PR for using dev version of keria in sigts. I will inline the problem description here in this issue:
I found that there is a problem when an agent that contains a delegator tries to resolve an oobi for its delegatee. See the added steps in
delegation.test.ts
for a reproduction. The effects of this is that you cannot create a "contact" for the delegate, which means you cannot send an IPEX message to the delegate. This is needed for doing IPEX grant from GLEIF External to the QVI.To reproduce this behaviour:
To explain what happens
After step 7, X nevers gets the AID of the delegator in its contact list. The oobi longrunning operation resolves with
Which only happens here: https://github.com/WebOfTrust/keria/blob/7ee5ba84c9aed5d2d21fa48d8241d39b06aadb93/src/keria/core/longrunning.py#L235-L239, when the AID is not in kevers.
Update: I have tried running the same tests using keria:latest and it works there.