Skip to content
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

feat: allow sending problem report when declining a proof request #1408

Conversation

Artemkaaas
Copy link
Contributor

Updated declineRequest method to acces optional sendProblemReport parameter indicating that Problem Report message also should be sent to Verifier.
Also updated sendProblemReport method to support connectionless proof request case.

@Artemkaaas Artemkaaas requested a review from a team as a code owner March 28, 2023 07:32
@codecov-commenter
Copy link

codecov-commenter commented Mar 28, 2023

Codecov Report

Merging #1408 (01b5330) into main (7459509) will increase coverage by 0.02%.
The diff coverage is 86.36%.

@@            Coverage Diff             @@
##             main    #1408      +/-   ##
==========================================
+ Coverage   85.34%   85.37%   +0.02%     
==========================================
  Files         788      788              
  Lines       19435    19446      +11     
  Branches     3159     3163       +4     
==========================================
+ Hits        16587    16602      +15     
+ Misses       2841     2837       -4     
  Partials        7        7              
Impacted Files Coverage Δ
packages/core/src/modules/proofs/ProofsApi.ts 86.93% <85.00%> (+2.89%) ⬆️
...e/src/modules/proofs/protocol/BaseProofProtocol.ts 57.14% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@Artemkaaas Artemkaaas force-pushed the feature/decline-connectionless-proof-request branch from 5d0ae3a to 4b973ed Compare March 28, 2023 08:14
Copy link
Contributor

@berendsliedrecht berendsliedrecht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple small points, but non-blocking for me.

@@ -368,13 +368,17 @@ export class ProofsApi<PPs extends ProofProtocol[]> implements ProofsApi<PPs> {
}
}

public async declineRequest(proofRecordId: string): Promise<ProofExchangeRecord> {
public async declineRequest(proofRecordId: string, sendProblemReport?: boolean): Promise<ProofExchangeRecord> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general we tend to create objects for functionality like named parameters. Here for example, calling declineProofRequest('abc-id', true) would be quite vague.

If we include this into 0.4.0 we can make the breaking change and the function would accept 1 parameter DeclineRequestOptions which is {proofRecordId: string, sendProblemRequest?: boolean}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you that accepting single parameter is better but I afraid to make breaking change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're just about to release 0.4.0 with a lot of breaking changes to the proofs api. Now is the time!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the method parameters to accept single DeclineProofRequestOptions object

// Assert
connectionRecord.assertReady()

const outboundMessageContext = new OutboundMessageContext(problemReport, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TimoGlastra is this the correct place to do this logic? If possbile I think it would be good to defer this to another method (creating the service decorator and adding it as serviceParams).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logical changes for send Problem Report function (handle connectionless request) repeats logic from accept Request method.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to refactor conecctionless in general. Once we integrate it with oob we can generalize the implementation and get rid of repeating the same code everywhere. For now I think it's fine to do it like this

serviceParams: {
service: recipientService.resolvedDidCommService,
senderKey: ourService.resolvedDidCommService.recipientKeys[0],
returnRoute: options.useReturnRoute ?? true, // defaults to true if missing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to define the default value either inside the function signature or at the first line. This is a bit hidden.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit sure if we need it. We don't expect a responsw to the problem report right? I'd just set it to false / leave it out

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed setting of returnRoute and useReturnRoute field in the parameters

@Artemkaaas Artemkaaas force-pushed the feature/decline-connectionless-proof-request branch from d57f2da to 1546215 Compare March 28, 2023 18:07
Copy link
Contributor

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's some issues with the sendProblemReport method still


await this.messageSender.sendMessage(outboundMessageContext)
return proofRecord
} else if (requestMessage?.service) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we want to send a problem report as the verifier? We'd send the message to ourselves in that case (as we're the ones that created the request). I think we shouldn't assume the role here, and instead infer it based on the state

Copy link
Contributor Author

@Artemkaaas Artemkaaas Apr 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added check that state is ProofState.RequestReceived but I had to move sending of the problem report before updating the state to Declined

@TimoGlastra TimoGlastra changed the title feat: Optionally send problem report when decline a proof request feat: allow sending problem report when declining a proof request Apr 10, 2023
@TimoGlastra TimoGlastra merged commit b35fec4 into openwallet-foundation:main Apr 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants