Feature/673 extend processpnboundmessagecommandhandler to allow for transaction creation #684

ognjenkurtic · 2023-05-15T20:52:08Z

Description

Introduces BpiMessage Transaction type and additional infrastructure that enables triggering of a command to create a BpiTransaction from a NATS incoming message which is properly formatted. Contains a number of TODOs that will be tackled as part of #669

Related Issue

#673
#669

Motivation and Context

Standard defines that a BpiTransaction can be triggered through a BpiMessage send via a messaging system utilized by the BPI.

How Has This Been Tested

Wrote new unit test and ran unit and e2e tests

Screenshots (if appropriate)

Types of changes

Bug fix (non-breaking change which fixes an issue)
[x ] New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Request to be added as a Code Owner/Maintainer

Checklist

My code follows the code style of this project.
My change requires a change to the documentation.
I have updated the documentation accordingly.
I have added tests to cover my changes.
All new and existing tests passed.
I commit to abide by the Responsibilities of Code Owners/Maintainers.

biscuitdey

createNewBpiMessage() is used in two cases: 1. creating a new message & publishing it; 2. in the processInboundMessage command handler. In both cases, the function takes id as a param.

Case 1: Where is the uuid for the message (id) generated?

Case 2: In the processInboundMessage command handler, we are assuming that the other participant has NOT created a new BpiMessage before publishing and sending us the message. But in the createBpiMessage, a message can only be published after creating a new BpiMessage. Wouldn't this cause the processInboundMessage to exit in bpiMessageAlreadyExists?

In the processInboundMessage, I think we should check that the message we have received corresponds to an existing BpiMessage, and we are only handling the tasks or receiving the information of a message already created by some other participant.

Kasshern · 2023-06-01T13:10:00Z

examples/bri-3/src/bri/transactions/agents/transactions.agent.ts

  public throwIfCreateTransactionInputInvalid() {
    // TODO: This is a placeholder, we will add validation rules as we move forward with business logic implementation
    return true;
  }

+  public isCreateTransactionInputInvalid(): boolean {


We need to be able to throw if the input is invalid and determine if the input is invalid without throwing?

Yes, we throw when we work with REST API and we do not throw when inside a background task (i.e. NATS message processing).

@ognjenkurtic do you intend to use a DeadLetterQueue to collect and process errors? I presume we can set up a NATS queue for that which is then processed by an error handler service, no?

Kasshern · 2023-06-01T13:17:12Z

examples/bri-3/src/bri/communication/agents/messaging.agent.spec.ts

+  it('Should return no errors and create message dto when validating correct JSON raw message of TRANSACTION type', () => {
+    // Arrange
+    const rawMessage =
+      '{ "id": "0a3dd67c-c031-4b50-95df-0bc5fc1c78b5", "fromBpiSubjectId": "71302cec-0a38-469a-a4e5-f58bdfc4ab32", "toBpiSubjectId": "76cdd901-d87d-4c87-b572-155afe45c128", "content": { "testProp":"testValue" }, "signature": "xyz", "type": 1}';


Perhaps the enum type should be given string designations

You mean for better readability? We can open a separate issue for that but i would not tackle it as a priority. What do you think?

not priority

Kasshern

Minor comments - Looks good overall

skosito

looks good, couple minor comments

skosito · 2023-06-10T16:50:42Z

examples/bri-3/src/bri/communication/agents/messaging.agent.ts

+      !newBpiMessageCandidate.isTransactionMessage()
+    ) {
+      errors.push(`type: ${newBpiMessageCandidate.type} is unknown`);
+      return [null, errors];


is there a reason to not just throw err or antything else, this seems a bit odd for ts

We want to collect all errors in one place and want to avoid throw as we are in a background task that should continue to execute

skosito · 2023-06-10T16:51:48Z

examples/bri-3/src/bri/communication/agents/messaging.agent.ts

-        newBpiMessageCandidate.type,
-      ),
-    );
+    if (newBpiMessageCandidate.isInfoMessage()) {


can this condition be checked in command handler since in both cases same command is called and that way we can isolate handling of different types on one place?

It is not the same command.

IsInfoMessage -> ProcessInboundBpiMessageCommand
isTransactionMessage -> ProcessInboundBpiTransactionCommand

skosito · 2023-06-10T16:52:36Z

examples/bri-3/src/bri/identity/bpiSubjectAccounts/agents/bpiSubjectAccounts.agent.ts

+  ): Promise<BpiSubjectAccount[]> {
+    const subjectAccounts: BpiSubjectAccount[] = [];
+
+    for (const subjectAccountId of subjectAccountIds) {


nit but shouldn't this be one query instead of one query per id?

Makes sense but i would do it as part of a separate issue. I just followed what was previously there, Chesterton's Fence style. I am going to open an issue to optimize this, not to affect approvals that already exits.

ognjenkurtic · 2023-07-04T13:46:06Z

createNewBpiMessage() is used in two cases: 1. creating a new message & publishing it; 2. in the processInboundMessage command handler. In both cases, the function takes id as a param.

Case 1: Where is the uuid for the message (id) generated?

Case 2: In the processInboundMessage command handler, we are assuming that the other participant has NOT created a new BpiMessage before publishing and sending us the message. But in the createBpiMessage, a message can only be published after creating a new BpiMessage. Wouldn't this cause the processInboundMessage to exit in bpiMessageAlreadyExists?

In the processInboundMessage, I think we should check that the message we have received corresponds to an existing BpiMessage, and we are only handling the tasks or receiving the information of a message already created by some other participant.

Case 1:

Standard requirement is that the ID is produced by the sender. Sender generates one and passes it as part of the request DTO.
[R112]
A BPI message MUST contain a unique message identifier that is generated by the sender.
This allows unique identification of the message through its lifecycle.

Case 2:

processInboundMessageCommandHandler deals with the situation when the sender uses NATS to initiate message creation and publishing to the recipient

createBpiMessageCommandHandler deals with the situation when the senders does the same thing via the REST API.

The logic in both is mostly the same - accept and parse input, create new message, publish message. Not sure what issue are you refering to. Let's walk through the code together on our next sync.

…ct message type

…tantiating a BpiMessage object via ctor

…cking for bpiSubjectAccounts

biscuitdey

Thanks for the explanation. LGTM.

Therecanbeonlyone1969

LGTM

Kasshern · 2023-07-07T21:20:18Z

examples/bri-3/src/bri/communication/agents/messaging.agent.spec.ts

+  it('Should return no errors and create message dto when validating correct JSON raw message of TRANSACTION type', () => {
+    // Arrange
+    const rawMessage =
+      '{ "id": "0a3dd67c-c031-4b50-95df-0bc5fc1c78b5", "fromBpiSubjectId": "71302cec-0a38-469a-a4e5-f58bdfc4ab32", "toBpiSubjectId": "76cdd901-d87d-4c87-b572-155afe45c128", "content": { "testProp":"testValue" }, "signature": "xyz", "type": 1}';


not priority

ognjenkurtic requested review from Kasshern, skosito, biscuitdey, Manik-Jain and Ybittan May 15, 2023 20:52

biscuitdey reviewed Jun 1, 2023

View reviewed changes

Kasshern reviewed Jun 1, 2023

View reviewed changes

Kasshern previously approved these changes Jun 1, 2023

View reviewed changes

skosito previously approved these changes Jun 10, 2023

View reviewed changes

ognjenkurtic added 5 commits July 4, 2023 16:05

Add BpiMessageType.Transaction and adjust messaging agent to handle it

16e09e4

Introduce processInboundTransaction with ahndler and trigger on corre…

e7465c2

…ct message type

Fix parsing and creation of bpi messages from raw JSON message by ins…

9336ca1

…tantiating a BpiMessage object via ctor

Add test to validate deserialization of info type bpi message

17f8ccd

Fix method name in processInboundTransactionCommand handler

91e7034

ognjenkurtic dismissed stale reviews from skosito and Kasshern via 91e7034 July 4, 2023 14:05

ognjenkurtic force-pushed the feature/673-extend-processpnboundmessagecommandhandler-to-allow-for-transaction-creation branch from 54c52f3 to 91e7034 Compare July 4, 2023 14:05

ognjenkurtic requested review from skarred14 and Therecanbeonlyone1969 as code owners July 4, 2023 14:05

Fix account and transaction controller tests by introducing proper mo…

8b912d8

…cking for bpiSubjectAccounts

biscuitdey approved these changes Jul 6, 2023

View reviewed changes

Therecanbeonlyone1969 approved these changes Jul 6, 2023

View reviewed changes

Kasshern approved these changes Jul 7, 2023

View reviewed changes

Therecanbeonlyone1969 merged commit 0e40e2b into main Jul 7, 2023

Therecanbeonlyone1969 deleted the feature/673-extend-processpnboundmessagecommandhandler-to-allow-for-transaction-creation branch July 7, 2023 21:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature/673 extend processpnboundmessagecommandhandler to allow for transaction creation #684

Feature/673 extend processpnboundmessagecommandhandler to allow for transaction creation #684

ognjenkurtic commented May 15, 2023

biscuitdey left a comment

Kasshern Jun 1, 2023 •

edited

Loading

ognjenkurtic Jul 4, 2023

Therecanbeonlyone1969 Jul 6, 2023

Kasshern Jun 1, 2023

ognjenkurtic Jul 4, 2023

Kasshern Jul 7, 2023

Kasshern left a comment

skosito left a comment

skosito Jun 10, 2023

ognjenkurtic Jul 4, 2023

skosito Jun 10, 2023

ognjenkurtic Jul 4, 2023 •

edited

Loading

skosito Jun 10, 2023

ognjenkurtic Jul 4, 2023

ognjenkurtic Jul 4, 2023

ognjenkurtic commented Jul 4, 2023

biscuitdey left a comment

Therecanbeonlyone1969 left a comment

Kasshern Jul 7, 2023

Feature/673 extend processpnboundmessagecommandhandler to allow for transaction creation #684

Feature/673 extend processpnboundmessagecommandhandler to allow for transaction creation #684

Conversation

ognjenkurtic commented May 15, 2023

Description

Related Issue

Motivation and Context

How Has This Been Tested

Screenshots (if appropriate)

Types of changes

Checklist

biscuitdey left a comment

Choose a reason for hiding this comment

Kasshern Jun 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kasshern left a comment

Choose a reason for hiding this comment

skosito left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ognjenkurtic Jul 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ognjenkurtic commented Jul 4, 2023

biscuitdey left a comment

Choose a reason for hiding this comment

Therecanbeonlyone1969 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kasshern Jun 1, 2023 •

edited

Loading

ognjenkurtic Jul 4, 2023 •

edited

Loading