Implement resend contract functionality
We've recycled this issue. Decided on complex. The related tasks have been created and are part of this issue.
Still under discussion, see: https://nl-x.slack.com/archives/C05V2U917DX/p1707230689228249
- when the retry-backoff mechanism has been completed, it is possible that the contract is still not sent
- come with a solution (list of functional requirement)
current limitations and restrictions:
- currently no retry mechanism is present
- the create contract has a
render with error
and can display the error on the page. However that same contract can be retrieved in the contract-detail page- the contract-detail page currently does not have any way of displaying the contract has not been send to one or more peers
- when a contract is sent to multiple peers a
errgroup
is used that means only one error is send back in case of one or multiple errors. This means it is not known:- one or more Peers have not received the contract
- if more peers have not received the contract, which peers have not received the contract
- the contract details page does not have a
render with error
and so no error handling is in place for possible retries
There are two possible approaches which are cumulative (one can start with the first and add the second later)
- simple - all or nothing approach
- complex - track (latest) send to peer x actions
simple
In the simple approach the errgroup
is kept when an error occurs the UI offers a resend. Since it cannot be known if more errors have occured the resend will resend to all peers present on the contract.
Another restriction is the ability to only send from the create contact
page and not the contract detail page
. Resending is only available for creating contracts, not for accepting/rejecting/revoking
contracts
complex
In the complex approach the errgroup
is replaced with channel
so all responses and possible errors are tracked. The last response to each peer on the contract is stored in the controller database. This enables finer grained resending, where the contract is only resend to the peer that has not received the contact yet (or the last signature on the contract). This also opens the possibility to display which Peer did not receive the contract (or signature) of the contact.
Since the responses of these peers are stored in the controller they can also be used in the contract-details
page resending possible errors on the accept/reject/revoke
actions.
Note: diagram says database of the controller
But storing this in the manager better fits the current responsibilities of the manager and controller. So the table should be added to the manager database