-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add CanCreateRelationshipUseCase and handling of expired RelationshipTemplates #212
Add CanCreateRelationshipUseCase and handling of expired RelationshipTemplates #212
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
packages/runtime/src/useCases/consumption/requests/AcceptIncomingRequest.ts
Outdated
Show resolved
Hide resolved
packages/consumption/test/modules/requests/IncomingRequestsController.test.ts
Outdated
Show resolved
Hide resolved
…b.com:nmshd/runtime into fix/handling-of-expired-relationshiptemplates
@britsta There's currently no updating of request expiration in case an accept request or a create relationship (or something like that) fails, it's only updated upon receiving the request. Since you originally put them in, I'd like to ask you specifically if you're fine with that |
@Magnus-Kuhn I'm not sure if I understand you quite right regarding the impact of a failing Request acceptance on the expiry update of a Request. What exactly do you mean by that? As I understand it, the Request expiry is still updated anytime when the getIncomingRequest (or getIncomingRequests) method is called. Therefore, especially, in the beginning of the AcceptIncomingRequest use case. ...But no longer, as you correctly said, in the CanCreateRelationship or CreateRelationship use case. @jkoenig134 prefers to remove this side effect from these use cases and that's fine for me, because the status is updated at the next time I call up a Request getter. Even if we could certainly discuss this further... :D |
@britsta I meant that the fact that the template expired was used to update the request - sorry I didn't make that clear |
No problem! I see, I think it is not necessary anymore if the |
#212 (comment) There's a discussion here, for me it's alright the way it is. |
@Magnus-Kuhn what's the issue here? I called yesterday with @britsta, everything is discussed and done together. |
That's on me @jkoenig134, I had a few more questions about a previous discussion, which @Magnus-Kuhn answered. All fine for me! 😊 |
If an App user scans a RelationshipTemplate containing a Request and only responds to the Request after the RelationshipTemplate has expired, no error message is shown. This problem is to be resolved by the Runtime throwing corresponding errors for expired RelationshipTemplates.
In connection with this, the CanCreateRelationshipUseCase has now also been added, in which an error can also be thrown due to an expired RelationshipTemplate.