Fabric chaincode life-cycle handling about caliper HOT 3 CLOSED

If I understand you correctly, the problem is that a transaction may has been committed even if sendTransaction returns a rejected promise.

A easy way to correct it is ignoring the REQUEST_TIMEOUT error and continuing waiting for all event promises. For other known errors such as SERVICE_UNAVAILABLE, there is no reason to continue, right?

What's your opinion?

BTW: since step 6 is optional, when would it be applied?

from caliper.

Exactly. In my fork, I essentially ignore the orderer response (only log the error). The event results will determine the final status of the transaction.

Another thought: I use Promise.All on the event promises, but Promise.Any would be enough I think. If one peer successfully commits the transaction, then every other peer will commit it eventually, so the occasional event hub error of one/some peers should not deem the transaction failed. However, if I want to calculate percentile-based commit times (as discussed by the PSWG), then I need every event notification.

About step 6: it is a little fuzzy whether this should be performed in the invokebycontext function, or as a post-processing step after the round that queries every failed, but not verified transaction. And whether to incorporate that query time somewhere or not. As a first step, I think Caliper should be able to mark such transactions as "verified after the life-cycle" to avoid false negative results and give the option for data analysts to ignore such transaction times during the analysis.

from caliper.

It sounds good. Would you please submit the PR? I'll be very happy to review it, thanks.

from caliper.