Did-exchange threading / connection identification

[Patrik-Stas]

When running did-exchange test
features/0023-did-exchange.feature:27 Establish a connection with DID Exchange between two agents with an explicit invitation with a public DID
(presumably others did-exchange test too, but didn't try)

AATH is making expectation that POST /agent/command/did-exchange/send-request returns

{ "connection_id": id }

whereas however, connection_id is in fact pthid of invitation (for invitee's side of protocol). Frankly I don't know if this is pattern commonly used in other suites too, but I intuitively I would expect thid to be identifier of an aries protocol (be it nested subprotocol).
Also worthy noting that on invitee's side of protocol, it's in fact thid which is used as protocol identifier - which I think further highlights the inconsistency.

[swcurran]

I suspect this is an ACA-Py-ism. ACA-Py deals with connection_ids for connections, and from there finds the rest of the details. I’m not sure of where thids come in. I suspect other backchannels support this (the issue has not been raised before), but it seems that thid kind of does make sense. Not sure what the backchannels (or ACA-Py at least) would have to maintain in order to convert thid to connection_id — or if the POST could return both values.

@nodlesh — thoughts?

[nodlesh]

I believe we decided on using connection_id here for compatibility across all of the Aries Frameworks. A quick look at AFJ and AFGO reveals that they seem to always provide a connection id on the oob/receive-invitation. The step before the did-exchange/send-request. I'm not sure they return a thid, a pthid or equivalent.
That said, in the And "Acme" receives the invitation step the connection id is treated conditionally. That is, it is expected that it may not exist. I guess it is always provided because the next step (the one you reference above) uses the requesters connection_id unconditionally. Maybe there was to be a conditional statement there as well but was overlooked or determined it was not needed because no framework worked that way.
This was done a long time ago now, and a more compatible way to cover this across frameworks may have emerged since then. Some investigation would be required to determine that.