Malfunction gateway submit bft about fabric HOT 7 CLOSED

In the standard bft client-server communication scheme, the client sends a query "2x2=?" and receives a calculation result of "4" from each node, collects a quorum of responses and concludes that 2x2=4.
In this variant, losing more nodes will result in an error.

In the fabric with the, the client sends a request "2x2=?" and receives a "accepted for processing" response from each node.
And quorum is collected by peers using BFTDeliverer.
The client receives the result of calculations from the peer.

Therefore, the broadcastToAll function should be rewritten as follows:

• if the request has not reached anyone, an error is returned
• if nodes >= quorum are reached, then we can successfully exit without waiting for all nodes to be reached.
• if at least one node has been reached, then success is also returned

from fabric.

my option is to submit bft

#4417

from fabric.

if at least one node has been reached, then success is also returned

why? if you reached a single node, including the transaction in a block is not guaranteed.

from fabric.

why? if you reached a single node, including the transaction in a block is not guaranteed.

Right, no guarantees, but in most cases (temporary failures) the transaction will be executed and delivered.
This is what the test shows (https://github.com/hyperledger/fabric/pull/4414/files), I removed Resubmitting and after the nodes returned, the transaction was executed.

But in the fabric we don't expect results from orders, we expect results from peers.

from fabric.

Now I have one point, the point of "it's not clear what happened" where I can stop, figure it out, and fix it. It's the point of waiting for an event from the peer. Your variant adds another such point for me: the error is back, but check it may not be an error.

Consequently, the client application to the fabric will have to become more complex. I would like to see such applications simplified.

from fabric.

If you send a transaction and it failed reaching a quorum of nodes, the right way to deal with it, is retrying and then it will hopefully reach a quorum of nodes.

In any case, the client application should be aware that once it submitted a transaction to the network, it may have been included in a block. That is the case for both CFT and BFT.

Sending the transaction only to 1 node will only delay its inclusion in a block and it's better to retry than to hope it will get in eventually.

from fabric.

I think it's a complication of the program and a suggestion to the client using the factory to rewrite their applications for bft.

from fabric.