Connection Properties Out of Sync

[jleach]

When a connection is established with an ACA-py agent and forwarded to the Controller via the POST /topic/connections/ HTTP/1.1 call, some properties are missing compared to the API call made to ACA-py to retrieve the same connection. This lack of synchronization between the two records requires the controller to make an additional call to the ACA-py agent to determine the connection state. This is important because, the Controller should not send messages as part of the connections/1.0 to the connection until it has entered the rfc23_state: completed state.

It's worth noting that ACA-py will send a POST to the controller every time the rfc23_state connection state changes. Usually, this means 3 POST requests. The controller must then check 3 times what was the state change to see if its safe to send a message.

Missing Fields

• my_did
• rfc23_state

Received Connection (POST)

{
  "state": "request",
  "created_at": "2023-09-22T16:47:14.292096Z",
  "updated_at": "2023-09-22T16:47:19.455361Z",
  "connection_id": "b3eef4a5-72a3-4c2d-a05e-ba8c88ab9f91",
  "their_did": "RkX8wYrnL5KAzjY3k6sswK",
  "their_label": "My Wallet - 5764",
  "their_role": "invitee",
  "connection_protocol": "connections/1.0",
  "invitation_key": "6bH4err7qHLPbd5iSLrz4Dfbnj7u7cavXuUncHYXP92H",
  "routing_state": "none",
  "accept": "auto",
  "invitation_mode": "once",
  "alias": "blarb7"
}

Fetched Connection (GET)

{
  "state": "response",
  "created_at": "2023-09-22T16:47:14.292096Z",
  "updated_at": "2023-09-22T16:47:19.483166Z",
  "connection_id": "b3eef4a5-72a3-4c2d-a05e-ba8c88ab9f91",
  "my_did": "9xwNP2m3BUsZuEBwiVCizc",
  "their_did": "RkX8wYrnL5KAzjY3k6sswK",
  "their_label": "My Wallet - 5764",
  "their_role": "invitee",
  "connection_protocol": "connections/1.0",
  "rfc23_state": "response-sent",
  "invitation_key": "6bH4err7qHLPbd5iSLrz4Dfbnj7u7cavXuUncHYXP92H",
  "routing_state": "none",
  "accept": "auto",
  "invitation_mode": "once",
  "alias": "blarb7"
}

[swcurran]

Looks like an easy one. @jleach — urgency on this one? What are you hitting.

ASIDE — a rant: the state and rfc23_state items are a pain that I think we made worse by keeping them both. IMHO What you are getting in this set of webhooks is information about the connection being established, vs. about the protocol that is used to create the connection. However, these webhooks are fired on the basis of the progress of the protocol used to create the connection, and for most protocols, the protocol information is what we need. This was made worse when the two protocols (0160, 0023) used different states for essentially the same thing — for no reason. It is perfectly reasonable to just use the state and expect it to always be the 0160 values. It’s too bad we didn’t think that through more a few years ago… rant over

Regardless of the rant — we still need to convey the full data in the webhook, so the issue needs to be addressed.

[jleach]

@swcurran Low. The work around is to make an API call to the agent which is fine for now.

[usingtechnology]

See work on #2434 .

That work doesn't explain why rfc23_state is not present in the webhook.

My best first guess is a logic gap in ConnRecord.State.rfc23strict

Note that above, the webhook is request... Would be interesting to see the payload when it hits response (as the GET state is response)... Check for logic the gap and check if subsequent payloads do return rfc23_state.

[usingtechnology]

@jleach - since there are many ways to establish a connection, can you document how the above connection was made?

[jamshale]

I can't seem to be able to replicate this with the faber/alice demo or with the mobile wallet. The webhook responses have the fields for all the states.

I do notice the fields missing in the wallet logs though. Perhaps it's an issue with the @aries-framework/core npm package and not acapy?

I'm going to wait on additional context before spending more time on this.

Faber | 2023-09-25 18:27:18,767 aries_cloudagent.core.event_bus DEBUG Notifying subscribers: <Event topic=acapy::record::connections::request, payload={'state': 'request', 'created_at': '2023-09-25T18:26:18.676041Z', 'updated_at': '2023-09-25T18:27:18.764881Z', 'connection_id': '5b25f3f6-14e7-444f-aeba-b57ce3e40aad', 'their_did': 'GWb3cn23jxQrUs4oKcqQ4Y', 'their_label': 'My Wallet - 6241', 'their_role': 'invitee', 'connection_protocol': 'connections/1.0', 'rfc23_state': 'request-received', 'invitation_key': 'CrG9FxptMUFbHykksiFFRgfPuWA9irbZ82DgwSjUKzov', 'accept': 'auto', 'invitation_mode': 'once'}>

Faber | 2023-09-25 18:27:18,768 aries_cloudagent.transport.outbound.http DEBUG Posting to http://172.17.0.1:8022/webhooks/topic/connections/; Data: {"state": "request", "created_at": "2023-09-25T18:26:18.676041Z", "updated_at": "2023-09-25T18:27:18.764881Z", "connection_id": "5b25f3f6-14e7-444f-aeba-b57ce3e40aad", "their_did": "GWb3cn23jxQrUs4oKcqQ4Y", "their_label": "My Wallet - 6241", "their_role": "invitee", "connection_protocol": "connections/1.0", "rfc23_state": "request-received", "invitation_key": "CrG9FxptMUFbHykksiFFRgfPuWA9irbZ82DgwSjUKzov", "accept": "auto", "invitation_mode": "once"}; Headers: {'Content-Type': 'application/json'}

[jamshale]

I might not be testing this correctly though. I'd like to check it by doing the websocket messages one at a time instead of using the alice/faber demo and bifold.

[swcurran]

Back to you, @jleach to provide more details. We suspect this might be happening somewhere other than in ACA-Py.

Can you provide some more detail or steps to reproduce?

[swcurran]

Reopen if this is still an issue.