Uploaded image for project: 'Fabric'
  1. Fabric
  2. FAB-13454

Possible Idempotency Issue while sending many transactions with same TxId - v1.3

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • High
    • Resolution: Invalid: Test Error
    • v1.3.0
    • None
    • fabric-peer
    • Hide
      CASE 1 - Idempotency is preserved
       
      1.1) Generate the TransactionID by calling "Client.newTransactionID()"
       
      1.2) Call "invoke" method
       
      1.3) Wait for the transaction to be validated
       
      1.4) Try to perform an "invoke" with the same TransactionID from step "1.1)" - Idempotency preserved
       
       
      CASE 2 - Idempotency is not preserved (strange behavior)
       
      2.1) Generate the TransactionID by calling "Client.newTransactionID()"
       
      2.2) Call "invoke" the chaincode multiple times, with the same TransactionID, before any of the transactions has time to be committed.
       
      2.3) Consult the status of the Ledger by "query" method. (In the Ledger state, all generated transaction states in step "2.2)" have been saved in CouchDB) - Idempotency not preserved. The same TransactionId produced several changes in the World State.
       
      2.4) See "Channel.queryTransaction(tx_id)". The transaction returned by the Ledger contains the payload of only one of the submitted transactions - Strange behavior
      Show
      CASE 1 - Idempotency is preserved   1.1) Generate the TransactionID by calling "Client.newTransactionID()"   1.2) Call "invoke" method   1.3) Wait for the transaction to be validated   1.4) Try to perform an "invoke" with the same TransactionID from step "1.1)" - Idempotency preserved     CASE 2 - Idempotency is not preserved (strange behavior)   2.1) Generate the TransactionID by calling "Client.newTransactionID()"   2.2) Call "invoke" the chaincode multiple times, with the same TransactionID, before any of the transactions has time to be committed.   2.3) Consult the status of the Ledger by "query" method. (In the Ledger state, all generated transaction states in step "2.2)" have been saved in CouchDB) - Idempotency not preserved. The same TransactionId produced several changes in the World State.   2.4) See "Channel.queryTransaction(tx_id)". The transaction returned by the Ledger contains the payload of only one of the submitted transactions - Strange behavior

    Description

       
      We found a possible Issue in Hyperledger Fabric 1.3.0 about Idempotency while sending many transactions with same TxId.
       
      SUMMARY
       
      Hyperledger Fabric does not guarantee the idempotency of the TransactionID, before it has been commited to the Ledger.
       
      DATABASE
       
      - CouchDB
       
      SCENARIO
       
      In Hyperledger Fabric, version 1.3, using a version of the "fabric-client:1.3.0SDK, I'm generating a new transaction with "newTransactionID()" method of the "Client" class.
       
      Based on TransactionID returned by the called method, I am performing an "invoke" on "chaincode", where the readset and writeset are dynamically generated, meaning there will be no version conflict. Because of that, transactions do not need to be serialized.
       
       

      Attachments

        1. configtx.yaml
          10 kB
        2. configtx.yaml
          4 kB
        3. Logfile.txt
          120 kB

        Activity

          People

            ales Alessandro Sorniotti
            emmanuel.kiametis Emmanuel Kiametis
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: