Implement Waiter method on contract clients #120

New issue

Closed

opened 2024-10-21 12:46:07 +00:00 by vdomnich-yadro · 1 comment

vdomnich-yadro commented

2024-10-21 12:46:07 +00:00

Member

Current implementation of Wait method in frostfsid client awaits for transaction to enter blockchain. However, it does not ensure that transaction entered blockchain with successful result. Checking transaction result in application code is not efficient: easy to overlook, code gets cumbersome. Solution (as we discussed it) is described below.

Describe the solution you'd like

It would be convenient if clients provided Waiter method that returns implementation of the Waiter interface from neo-go. Implementation can be configured with options:

Whether already exists error should be ignored or not.
Whether transaction execution results should be examined or not.

Describe alternatives you've considered

Checking transaction results in application code seems suboptimal (see explanation above).
Maintaining waiter implementation alongside with contract client is bearable, but not convenient.
Implementing waiter as sequence of transaction inspectors (middleware in chain-of-responsibility pattern) is flexible, but difficult to grasp and reason about.

Additional context

## Is your feature request related to a problem? Please describe. Current implementation of Wait method in frostfsid client awaits for transaction to enter blockchain. However, it does not ensure that transaction entered blockchain with successful result. Checking transaction result in application code is not efficient: easy to overlook, code gets cumbersome. Solution (as we discussed it) is described below. ## Describe the solution you'd like It would be convenient if clients provided Waiter method that returns implementation of the `Waiter` interface from neo-go. Implementation can be configured with options: - Whether `already exists` error should be ignored or not. - Whether transaction execution results should be examined or not. ## Describe alternatives you've considered - Checking transaction results in application code seems suboptimal (see explanation above). - Maintaining waiter implementation alongside with contract client is bearable, but not convenient. - Implementing waiter as sequence of transaction inspectors (middleware in chain-of-responsibility pattern) is flexible, but difficult to grasp and reason about. ## Additional context ---