fabric icon indicating copy to clipboard operation
fabric copied to clipboard

Blockchain transaction failing because of TransacionEventHandler and no response from peers

Open piyushaNeo opened this issue 1 year ago • 1 comments

What happened?

Normal transactions used to work fine & all blockchain transactions were getting committed. We have never faced issues earlier ever as this transaction is normal transaction which we are regularly do. All of a sudden the blockchain transaction is not getting committed & fails.

What did you expect to happen? To commit blockchain transactions as usual

Anything else we need to know? On checking logs of API, it says that no peers reponded & event strategy error related to timeout.

ERROR [TransactionEventHandler]: strategyFail: commit failure for transaction "5c6e2d49c66b09fc7849815488f81ce5ccd57b7b7707fcd4815bc3e53f6db464": TimeoutError: Event strategy not satisfied within the timeout period. No response received from peers: peer0-org1:7051 at TransactionEventHandler.timeoutFail (/usr/src/app/node_modules/fabric-network/lib/impl/event/transactioneventhandler.js:125:23) at Timeout._onTimeout (/usr/src/app/node_modules/fabric-network/lib/impl/event/transactioneventhandler.js:112:18) at listOnTimeout (internal/timers.js:554:17) at processTimers (internal/timers.js:497:7) { transactionId: '5c6e2d49c66b09fc7849815488f81ce5ccd57b7b7707fcd4815bc3e53f6db464' } [TransactionEventHandler]: setListenTimeout - event handler timed out error from invoke function :: Event strategy not satisfied within the timeout period. No response received from peers: peer0-org1:7051

Comment/Questions

  • What can be the issue in this case as my peer/orderer pods are up & running.
  • Is there any parameter tuning configuration which needs to be increased or adjusted?
  • Any timeout/retry count parameter with a retry delay to be done?
  • What precautions can be taken so that we do not encounter this issue in future - Requesting your guidance & suggestions fabric maintainers!

piyushaNeo avatar Mar 23 '23 13:03 piyushaNeo

It seems that the client did not observe a block event from peer0-org1 that contained the transaction before it gave up waiting after a timeout period. The transaction might have been successfully committed but the client is not able to tell either way since it was not able to obtain the validation code.

This behaviour can occur if an ingress controller or proxy along the route between client and peer is too aggressively closing idle connections or long-lived connections used by the client to stream blocks from the peer. Configuring appropriate gRPC keepalive settings at the client end can help mitigate this issue by ensuring the connection is never idle long enough to be closed.

It's worth checking peer logs from peer0-org1 to see if anything happened at that end. Also if the client application picked up a more recent version of the Node SDK dependencies that has triggered an issue for you, although the current release version is passing daily integration testing OK.

I will also point out that, if you are using Fabric v2.4+, the Fabric Gateway client API allows you easier control of timeouts and to implement retry of specific stages in the transaction flow using the async and fine-grained transaction submit flows, described in the API documentation.

bestbeforetoday avatar Mar 23 '23 13:03 bestbeforetoday