-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(oob): support oob with connection and messages #1558
fix(oob): support oob with connection and messages #1558
Conversation
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Codecov Report
@@ Coverage Diff @@
## main #1558 +/- ##
===========================================
- Coverage 85.73% 62.59% -23.14%
===========================================
Files 950 774 -176
Lines 22761 17843 -4918
Branches 3982 3069 -913
===========================================
- Hits 19514 11169 -8345
- Misses 3062 6136 +3074
- Partials 185 538 +353
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of very minor points, otherwise LGTM.
@@ -297,8 +297,11 @@ async function addExchangeDataToMessage( | |||
associatedRecord: BaseRecordAny | |||
} | |||
) { | |||
const legacyInvitationMetadata = outOfBandRecord?.metadata.get(OutOfBandRecordMetadataKeys.LegacyInvitation) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this file has an unused import from http
which is a mistake, but not from your PR. Can you remove it?
GitHub does not allow me to add a comment there...
// Set the parentThreadId on the message from the oob invitation | ||
if (outOfBandRecord) { | ||
// If connectionless is used, we should not add the parentThreadId | ||
if (outOfBandRecord && legacyInvitationMetadata?.legacyInvitationType !== 'connectionless') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make more sense to have legacyInvitationType
be an enum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah probably :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In ConnectionRecord
we have the protocol
field where we define the handshake protocol for the DID Exchange, and in the case of DIDComm V2, where no handshake protocol is involved, we set it to None
. If this legacyInvitationType
refers to the message type, would it make sense to call it 'none'. in the case of a connection-less exchange?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it make sense to call it 'none'. in the case of a connection-less exchange?
Well in that case we don't know explicitly if it's a connectionless message, and we have custom behaviour for that as you can see here. I'd still call a message with a ~service
an invitation to do something.
So invitation type here refers less to connections, and more to an invitation to an exchange that is sent not over didcomm. (connectionless, connection v1, oob v1, etc..)
*/ | ||
public async matchIncomingMessageToRequestMessageInOutOfBandExchange( | ||
messageContext: InboundMessageContext, | ||
{ knownConnectionId }: { knownConnectionId?: string } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it should be
{ knownConnectionId }: { knownConnectionId?: string } | |
{ expectedConnectionId }: { expectedConnectionId?: string } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that makes sense. I was thinking if it is undefined it doesn't make sense. But after thining about it again, if it's undefined we don't really expect a specific connection Id
packages/core/src/modules/oob/repository/outOfBandRecordMetadataTypes.ts
Show resolved
Hide resolved
// Set the parentThreadId on the message from the oob invitation | ||
if (outOfBandRecord) { | ||
// If connectionless is used, we should not add the parentThreadId | ||
if (outOfBandRecord && legacyInvitationMetadata?.legacyInvitationType !== 'connectionless') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In ConnectionRecord
we have the protocol
field where we define the handshake protocol for the DID Exchange, and in the case of DIDComm V2, where no handshake protocol is involved, we set it to None
. If this legacyInvitationType
refers to the message type, would it make sense to call it 'none'. in the case of a connection-less exchange?
* If is the case, and the state of the out of band record is still await response, the state will be updated to done | ||
* | ||
*/ | ||
public async matchIncomingMessageToRequestMessageInOutOfBandExchange( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow this is a huge method with a huge name!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, i like explicitness over being brief. But suggestions welcome! :)
Signed-off-by: Tom Lanser <tom@devv.nl>
Signed-off-by: Tom Lanser <tom@devv.nl>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
…tion#1558) Signed-off-by: Timo Glastra <timo@animo.id> Signed-off-by: Ariel Gentile <gentilester@gmail.com>
…tion#1558) Signed-off-by: Timo Glastra <timo@animo.id> Signed-off-by: Martin Auer <martin.auer97@gmail.com>
…tion#1558) Signed-off-by: Timo Glastra <timo@animo.id> Signed-off-by: Martin Auer <martin.auer97@gmail.com>
Fixes #1129
We now correctly check whether an oob exchange is associated with an exchange if there's no connectionId, and assign the connection if this is the case.
I think we now really support al flows and combinations of messages / handhsake / connectionless from the oob protocol.