Re: The return value in Fabric gateway java SDK submitTransaction method

Mark Lewis

If the transaction has been committed (i.e. the submit() call returns successfully) then it has satisfied the endorsement policy. If the endorsement policy wasn't satisfied then the transaction would be unsuccessful.

Regardless, if all you want to do is inspect a previously committed transaction then you do have several options using the fabric-gateway-java API, two of which I think you already understand:
  1. Look through block events received from peers for the required transaction event. This can be done realtime (in which case you would want to attach your listener before submitting the transaction), or you can replay previous blocks. Your listener will receive one block event for each block, and these will be received in block order.
  2. Use a commit listener to listen in realtime only for a specific transaction event from all specified peers. You will receive at most one transaction event from each peer.
  3. Use Network.evaluateTransaction() to retrieve a specific transaction directly from the Query system chaincode (qscc) GetTransactionByID transaction function. Just be aware that the response payload will be a serialized protobuf that you will need to deserialize. Compiled protobufs are in the org.hyperledger.fabric.protos package within the fabric-sdk-java JAR. The source repository for those protobuf definitions isĀ

Be aware that, while you can access the parent transaction for a given contract event, a contract event listener will only be invoked if:
  1. The transaction function emitted a chaincode event.
  2. The transaction committed successfully.

There is no guarantee on whether event delivery to different listeners is serial or parallel. The only guarantee is that each block (or contract) listener will receive events in block order and without duplication. From memory, the current implementation does deliver events to all realtime listeners sequentially, but the order of invocation of those realtime listeners is non-deterministic. Since this in an implementation detail, you shouldn't rely on this behaviour remaining the same across releases.

Join to automatically receive all group messages.