Reusing peer DID for invitation resulting in DID Ex failure

[dbluhm]

When using the new feature of using a did:peer:4 or did:peer:2 and not requiring the creation of a new unique did using the create_unique_did parameter, the first DID Exchange request will succeed. However, subsequent DID Exchange requests will fail with the following error:

2024-04-12 19:54:59,069 aries_cloudagent.core.conductor ERROR Exception in message handler:
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/asyncio/tasks.py", line 256, in __step
    result = coro.send(None)
  File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/core/dispatcher.py", line 210, in handle_message
    await handler(context, responder)
  File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/protocols/didexchange/v1_0/handlers/request_handler.py", line 36, in handle
    conn_rec = await mgr.receive_request(
  File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/protocols/didexchange/v1_0/manager.py", line 525, in receive_request
    conn_rec = await self._receive_request_pairwise_did(
  File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/protocols/didexchange/v1_0/manager.py", line 548, in _receive_request_pairwise_did
    conn_rec = await ConnRecord.retrieve_by_invitation_key(
  File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/connections/models/conn_record.py", line 314, in retrieve_by_invitation_key
    return await cls.retrieve_by_tag_filter(session, tag_filter, post_filter)
  File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/messaging/models/base_record.py", line 265, in retrieve_by_tag_filter
    raise StorageDuplicateError(
aries_cloudagent.storage.error.StorageDuplicateError: Multiple ConnRecord records located for {'invitation_key': 'CkUeVgdsn2eiZ6s9jAvHVNDPYtD8yph9uq1eS1phnQ8N', 'state': 'invitation', 'their_role': 'invitee'}, {'state': 'invitation', 'their_role': 'invitee'}

Previously, the DID Exchange manager depended on looking up a unique connection by invitation_key when the request was not to a public DID. Given that the same DID was used for both invitations, the invitation_key would be the same and the look up fails.

If using the invitation as a multi-use invitation, the DID exchange succeeds. This occurs only when generating unique invitations but using the same DID.

[dbluhm]

I suspect this scenario was addressed in the original did:peer:2/4 reuse PR and I inadvertently clobbered the changes when I was addressing the use_did_method and use_did additions.

[swcurran]

Do you think we need a 0.12.1 for this one?

[dbluhm]

Yes, unfortunately. Otherwise, the only way to achieve using invites with did:peer:2/4 would be through multi-use invitations. And even then, I suspect there may be some subtle issues because of the old expectation of 1 invitation key to 1 connection record. I've addressed everywhere but in the connection protocol implementation in #2891.