Request Duplicate Check

[NicoDuvenage]

Request:

Please verify the Request Duplicate Check Design - see associated Sequence Diagram

Artifacts:

• [x] https://docs.google.com/document/d/18zNB7ShWS5NiNdlAWffup5G5eOUtAwycTFyI3cni34c [@ggrg]

Decision(s):

• [x] Actual decision made as a result of discussion --> Option 4

Follow-up:

• options:
  1. add completedRequest table a. <-- full accordance with the spec, insert ALL requests, which will support PUT operations b. <-- full accordance with the spec, insert only for invalid requests, which will support PUT operations
  2. simplify API by removing GET response on POST/PUTs and just respond with a "DUPLICATE ERROR"
  3. minimal validations up-front (pre-validations) prior to hash-check where we only store requests that "can be PROCESSED" by either the prepare or the fulfil handler and send the failed pre-validations to the audit log
  4. support inserting invalid transfers with minimal info required (e.g. transferId, status,etc) - use existing db structures - https://github.com/mojaloop/design-authority/issues/9
     • prepare <-- will resolve the issues there
     • fulfil <-- does not resolve requests being sent from incorrect FSPs? (edited)

Dependencies:

• [x] #780, #781

Accountability:

• Owner: @ggrg

Notes:

[NicoDuvenage]

The detail on the proposed solution after a meeting concluded on Jun 3, 2019, @ 19:00 SAST To be presented by Georgi to DA on Jun 4 and discussions to be held over for the regular weekly DA meeting on Wednesday. options:

1. add completedRequest table a. <-- full accordance with the spec, insert ALL requests, which will support PUT operations b. <-- full accordance with the spec, insert only for invalid requests, which will support PUT operations
2. simplify API by removing GET response on POST/PUTs and just respond with a "DUPLICATE ERROR"
3. minimal validations up-front (pre-validations) prior to hash-check where we only store requests that "can be PROCESSED" by either the prepare or the fulfil handler and send the failed pre-validations to the audit log (edited)

[NicoDuvenage]

At the DA meeting on Jun 5th, 2019, an additional option (4) was added and seemed to be the one worth investigating further. A meeting between interested parties will be arranged for Friday, Jun 7th after which this log will be updated with the recommended approach.

[mdebarros]

The decision has been made by the DA to proceed with option:

• 4. support inserting invalid transfers with minimal info required (e.g. transferId, status,etc) - use existing db structures

In addition the DA made the decision that the Fulfilments should be immutable. This means that when a fulfiment is received it should be processed and be the final outcome of that specific transfer. E.g. if the fulfiment is invalid, it should be aborted and notifications sent out to the respective participants.

The only special case for this is when the fulfiment is sent from an invalid FSP (aka a non-participating FSP). The switch will NOT use the headers to route the notifications messages, but rather instead lookup the correct participants from the DB store to route the message appropriately.

This will then ensure:

• Fulfil requests can't be gamed by multiple invalid attempts. This will harden the security aspects of the transfers.
• Also ensures that all involved participants will be informed that there has been some invalid request received as a result of being notified.
• A new transfer will need to be created from the prepare stage if the transaction is to be retried.
• It will also simplify the solution/implementation of duplicate-checks because it will be handled exactly in the same way as the prepare stage as there will be symmetry between for both request handling.

[mdebarros]

Next steps:

• Duplicate-check design to be updated to reflect the above decision. [ @ggrg ]
• Story to update the Central-Ledger Prepare Handler to insert incomplete/invalid transfer records with all/as-much information as possible into the existing db structure. [ @elnyry, @mdebarros ]
• Story to re-factor the fulfilment handler to align the validations (specifically the duplication-check) in the same fashion as the prepare handler. [ @elnyry, @mdebarros ]

[elnyry-sam-k]

Thanks Miguel, this looks good.