Open TimoGlastra opened 2 years ago
Good to have a definition of the desired behaviour.
Presumably the desired behaviour is to mark the state as "abandoned" and the webhook to the controller would at least show the invitation to be bad. If auto-accept is enabled, there really is nothing we can do as the controller doesn't care, and the invitation sender can't be contacted.
Another reason to get rid of many (all?) of the auto-
parameters in favour of having a default controller (in each language...) that implements the auto behaviours. But perhaps that's a topic for another day.
Yeah hadn't thought about the desired behaviour yet.
The ideal behaviour I would say is just doing a check before processing the invitation and throwing an error. We could check whether the transport is supported. This way the connection record (and keys) are never created if it is not possible to connect.
AFGO does this for DIDExchange invitation (returns http error) (implemented before oob invitation) but logs an error (not visible in the rest API) for OOB.
When receiving an out-of-band invitation (I assume the same is true for connections protocol invitation) where the transport protocol (http, ws, etc..) is unsupported, ACA-Py will swallow it and making it almost undetectable the receiving of the invitation failed.
The record state will be updated to request-sent (if auto-accept is enabled) and ACA-Py will log the following warning:
It's not possible currently to detect the sending has actually failed because there is not outbound transport that can send the message.