WebOfTrust
is:issue KERIA server exits (exit code 1) on admit call with 'NoneType' object has no attribute 'ked'
Version
0.2.0-rc2
Environment
Docker Image weboftrust/keria:0.2.0-rc2. Calling from the Java Signify Client
Expected behavior
The KERIA program should not exit on an issue triggered from the client calling admit
Actual behavior
keria-1 | keri: Parsed Request: POST /identifiers/keriAgent/ipex/admit (1, 1)
keria-1 | keri: Headers/Body: Hict([('Connection', 'Upgrade, HTTP2-Settings'), ('Content-Length', '528'), ('Host', 'localhost:3901'), ('HTTP2-Settings', 'AAEAAEAAAAIAAAAAAAMAAAAAAAQBAAAAAAUAAEAAAAYABgAA'), ('Upgrade', 'h2c'), ('User-Agent', 'Java-http-client/23.0.2'), ('content-type', 'application/json'), ('signature', 'indexed="?0";signify="0BBqKVNCb-HcKYncyo28v_R4wIhs3bcwOUJDeSGXtKgiO7CNKDeJURYa_m1u7t1AdrdEgNjpJqVxB3pgG3PQWs4D"'), ('signature-input', 'signify=("@method" "@path" "signify-resource" "signify-timestamp");created=1752618550;keyid="DEIQTAHbkR3wSqIwg-BRvdEjXaraN1zPo2NEiVD2Nw_n";alg="ed25519"'), ('signify-resource', 'EKQ8sRffgpUG2IC-0EbzLHJp2xfSewfbi9LLKZbndU0c'), ('signify-timestamp', '2025-07-15T22:29:10.892000+00:00')]) -- bytearray(b'{"exn":{"v":"KERI10JSON000164_","t":"exn","d":"EKeAFz6swWFoPqHqXeUpYh2e2d8Ksoi-Rzah5G-lHFLX","i":"ENfZkfmDtUGdkRKJIcxUPIpca7KDooN1MrJIPlIeCL3R","rp":"EM3DHzZstvF3gcLdLClWqVOTMu3aZmAu7jtbqjKUjby7","p":"0AAvEoCq3W4Sh9dPP7rir-VI","dt":"2025-07-15T22:29:10.662000+00:00","r":"/ipex/admit","q":{},"a":{"i":"EM3DHzZstvF3gcLdLClWqVOTMu3aZmAu7jtbqjKUjby7","m":""},"e":{}},"sigs":["AAA0JHN7ldUUPu083flIxQpjq7onS47-xVWhgmMbzGjIWu7ilwbEKyAALxxg13e1OYoT3jDOuTRS4pGC9t-ZTKsH"],"atc":"","rec":["EM3DHzZstvF3gcLdLClWqVOTMu3aZmAu7jtbqjKUjby7"]}')
keria-1 | keri: Behavior for /ipex/admit missing or does not have verify for said=EKeAFz6swWFoPqHqXeUpYh2e2d8Ksoi-Rzah5G-lHFLX
keria-1 | keri: event=
keria-1 | {
keria-1 | "v": "KERI10JSON000164_",
keria-1 | "t": "exn",
keria-1 | "d": "EKeAFz6swWFoPqHqXeUpYh2e2d8Ksoi-Rzah5G-lHFLX",
keria-1 | "i": "ENfZkfmDtUGdkRKJIcxUPIpca7KDooN1MrJIPlIeCL3R",
keria-1 | "rp": "EM3DHzZstvF3gcLdLClWqVOTMu3aZmAu7jtbqjKUjby7",
keria-1 | "p": "0AAvEoCq3W4Sh9dPP7rir-VI",
keria-1 | "dt": "2025-07-15T22:29:10.662000+00:00",
keria-1 | "r": "/ipex/admit",
keria-1 | "q": {},
keria-1 | "a": {
keria-1 | "i": "EM3DHzZstvF3gcLdLClWqVOTMu3aZmAu7jtbqjKUjby7",
keria-1 | "m": ""
keria-1 | },
keria-1 | "e": {}
keria-1 | }
keria-1 |
keria-1 | keri: Behavior for /ipex/admit missing or does not have handle for said=EKeAFz6swWFoPqHqXeUpYh2e2d8Ksoi-Rzah5G-lHFLX
keria-1 | keri: event=
keria-1 | {
keria-1 | "v": "KERI10JSON000164_",
keria-1 | "t": "exn",
keria-1 | "d": "EKeAFz6swWFoPqHqXeUpYh2e2d8Ksoi-Rzah5G-lHFLX",
keria-1 | "i": "ENfZkfmDtUGdkRKJIcxUPIpca7KDooN1MrJIPlIeCL3R",
keria-1 | "rp": "EM3DHzZstvF3gcLdLClWqVOTMu3aZmAu7jtbqjKUjby7",
keria-1 | "p": "0AAvEoCq3W4Sh9dPP7rir-VI",
keria-1 | "dt": "2025-07-15T22:29:10.662000+00:00",
keria-1 | "r": "/ipex/admit",
keria-1 | "q": {},
keria-1 | "a": {
keria-1 | "i": "EM3DHzZstvF3gcLdLClWqVOTMu3aZmAu7jtbqjKUjby7",
keria-1 | "m": ""
keria-1 | },
keria-1 | "e": {}
keria-1 | }
keria-1 |
keria-1 | keri: Shutting down main Doist loop
keria-1 | Traceback (most recent call last):
keria-1 | File "/keria/venv/bin/keria", line 8, in
Steps to reproduce
Not exactly sure yet but I suspect one of my parameters to the admit call is resulting in some information not found on the server.
The p (previous) value for an admit must point to the related grant message in the chain. It should point to the SAID of the grant message, which is the d field of the exn/exchange message.
Looking at your output, it seems your are using the ID (i) of the grant notification, not the exchange message itself - which is a.d in the notification.
However, yes, the Admitter should handle this better and not crash so can take a look. Easy fix, but it should probably also do this check at the API level to give Signify feedback.
Yeh, I figured I was likely passing the wrong thing but looks like there should be something in the main program that should catch and report and error rather than die. Thanks Fergal
On Wed, Jul 16, 2025 at 8:13 AM Fergal @.***> wrote:
iFergal left a comment (WebOfTrust/keria#371) https://github.com/WebOfTrust/keria/issues/371#issuecomment-3078803696
The p (previous) value for an admit must point to the related grant message in the chain. It should point to the SAID of the grant message, which is the d field of the exn/exchange message.
Looking at your output, it seems your are using the ID (i) of the grant notification, not the exchange message itself - which is a.d in the notification.
However, yes, the Admitter should handle this better and not crash so can take a look. Easy fix, but it should probably also do this check at the API level to give Signify feedback.
— Reply to this email directly, view it on GitHub https://github.com/WebOfTrust/keria/issues/371#issuecomment-3078803696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2AWHRCSN56KOBMO6NOLMD3IZM2FAVCNFSM6AAAAACBTIHKY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYHAYDGNRZGY . You are receiving this because you authored the thread.Message ID: @.***>
Perhaps other API calls may also be susceptible to bad input data and a default exception/error handler could prevent the server from exiting
On Wed, Jul 16, 2025 at 8:18 AM Barry Kreiser @.***> wrote:
Yeh, I figured I was likely passing the wrong thing but looks like there should be something in the main program that should catch and report and error rather than die. Thanks Fergal
On Wed, Jul 16, 2025 at 8:13 AM Fergal @.***> wrote:
iFergal left a comment (WebOfTrust/keria#371) https://github.com/WebOfTrust/keria/issues/371#issuecomment-3078803696
The p (previous) value for an admit must point to the related grant message in the chain. It should point to the SAID of the grant message, which is the d field of the exn/exchange message.
Looking at your output, it seems your are using the ID (i) of the grant notification, not the exchange message itself - which is a.d in the notification.
However, yes, the Admitter should handle this better and not crash so can take a look. Easy fix, but it should probably also do this check at the API level to give Signify feedback.
— Reply to this email directly, view it on GitHub https://github.com/WebOfTrust/keria/issues/371#issuecomment-3078803696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2AWHRCSN56KOBMO6NOLMD3IZM2FAVCNFSM6AAAAACBTIHKY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYHAYDGNRZGY . You are receiving this because you authored the thread.Message ID: @.***>
AFAIK in this case the API call is successful and it puts the admit on a internal queue, and the error is happening when the Doer picks it off the queue to send it. This is the general pattern in KERIA, and in this case a necessary one because in the case of multi-sig the admit won't be sent until other signatures are async gathered.
So I think if the error happens in the controller you will get a 500 and it won't crash - this is just happening outside the controller in the background. But yes, some work should be done to check other APIs for these kinds of issues - especially as it means one Signify client can take down KERIA for other clients.
@bkreiser IPEX was using the wrong parser, so it wasn't running the validation on IPEX message formats. The result is now the server won't crash, but the long running operation will stay running as it'll never complete.
We can add more validation in the controllers but there is technically more that should be checked than just the existence of the grant, so I'm thinking it would be better if the long running operation goes to the Failed state instead. This requires a bit of work in keripy though AFAIK so the operation tracker knows something went wrong in parsing.
Thanks for the update
On Tue, Sep 9, 2025 at 5:33 AM Fergal @.***> wrote:
iFergal left a comment (WebOfTrust/keria#371) https://github.com/WebOfTrust/keria/issues/371#issuecomment-3270274862
@bkreiser https://github.com/bkreiser IPEX was using the wrong parser, so it wasn't running the validation on IPEX message formats. The result is now the server won't crash, but the long running operation will stay running as it'll never complete.
We can add more validation in the controllers but there is technically more that should be checked than just the existence of the grant, so I'm thinking it would be better if the long running operation goes to the Failed state instead. This requires a bit of work in keripy though AFAIK so the operation tracker knows something went wrong in parsing.
— Reply to this email directly, view it on GitHub https://github.com/WebOfTrust/keria/issues/371#issuecomment-3270274862, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2AWHRM65AVHXSFDS36HOT3R23JXAVCNFSM6AAAAACBTIHKY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENZQGI3TIOBWGI . You are receiving this because you were mentioned.Message ID: @.***>
This has been reverted due to another issue that was caused. Re-opening for now