Separate logging of warnings and errors in channel.sendTransaction() method in low level java SDK

[ptippett]

We have observed that below ERROR level log is getting printed for every invalid transaction sdk receives and we think that this log should be at INFO level.
Receiving invalid transaction should not be considered as failure case, it is a BAU case.

2021-11-22 12:00:02.254 [pool-6-thread-173] ERROR Channel - Future completed exceptionally: sendTransaction
org.hyperledger.fabric.sdk.exception.TransactionEventException: Received invalid transaction event. Transaction ID b9c18e9a84ef12a4e3b553816c5bf008c4c9469a675631f0f508539d55b851ff status 11
at org.hyperledger.fabric.sdk.Channel$TL.lambda$fire$2(Channel.java:6866) ~[fabric-sdk-java-2.2.3.jar!/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_271]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_271]

Using low level java sdk 2.2.3.

After some discussion, the issue is that if the low-level fabric-sdk-java Channel.sendTransaction() method is used directly and configured (or defaults) to waiting for transaction commit events, an MVCC_READ_CONFLICT can occur and will be logged as an error in the SDK log. However this is not technically an error as an MVCC_READ_CONFLICT means the transaction is properly invalidated until the world state is read again.

Unfortunately, the logging for the Channel.sendTransaction() method uses the same code path for logging real transaction failures as well as non failures such as MVCC_READ_CONFLICTS.

The request is that a change be made such that actual errors are logged as errors and non errors are logged as info or warning. I believe this would require the code to try and guess the severity from a transaction validation code if one is associated with the error.

We also discussed changing the log level for any errors from Channel.sendTransaction() to warning. However, this would mask real errors in the logs and may affect other users who are scraping the logs for error messages.

The high level SDK uses a different flow so does not have this issue. Obviously though it's work for users to move to that SDK who are already using the low level SDK.