Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After a transaction, utxosAt returns the spent and produced utxos #124

Closed
alegadea opened this issue Nov 18, 2021 · 3 comments · Fixed by #185
Closed

After a transaction, utxosAt returns the spent and produced utxos #124

alegadea opened this issue Nov 18, 2021 · 3 comments · Fixed by #185
Labels
bug Something isn't working

Comments

@alegadea
Copy link
Contributor

Summary

It seems the function utxosAt doesn’t work properly. The function is returning sometimes the complete list of “utxos” for a given address, including the utxos that were already spent (together with “new” utxos generated on the same transaction that spent these others utxos). For instance, the following contract generates a utxo blocking 3 adas, that later we can spend and replicate again with a particular endpoint and after that action, the utxosAt function is returning both utxos the old one (which should be already spent) and the new one. It seems to be inconsistent.

Steps to reproduce

Steps to reproduce the behavior:

  1. Clone from this repository
  2. Start PAB with the bug-contract
  • cabal build contract
  • cabal exec -- contract --config pab-config.yml migrate
  • cabal exec -- contract --config pab-config.yml webserver --passphrase [PASS]
  1. Execute

The first step is to activate a contract instance with

  • curl -H "Content-Type: application/json" -v -X POST -d "{"caID":[],"caWallet {"getWalletId":"$WALLET_ID"}}" localhost:9080/api/contract/activate

After that, we can look up the utxos of that particular address

  • curl -X 'POST' 'http://localhost:9080/api/contract/instance/'$CID'/endpoint/utxos' -H 'accept: application/json;charset=utf-8' -H 'Content-Type: application/json;charset=utf-8' --data-raw '[]'

If everything goes well, we should see on the PAB a log message like this in which we can see a list with a single utxo

[pab:Info:43] [2021-11-18 17:03:34.63 UTC] 555fb4ce-378b-4075-9840-5a5f684adfcd: "Calling utxos endpoint."
[pab:Info:43] [2021-11-18 17:03:34.65 UTC] 555fb4ce-378b-4075-9840-5a5f684adfcd: "Got utxos: fromList [(TxOutRef {txOutRefId = 6a5041a79715c6328e149718b3fb80b5a248bf914e392f806d221bd18cc3bc42, txOutRefIdx = 0},ScriptChainIndexTxOut {_ciTxOutAddress = Address {addressCredential = ScriptCredential 146e8d6949db0f40cc8bc8531f8a8cb6f28dfc105f24c454cb8489ac, addressStakingCredential = Nothing}, _ciTxOutValidator = Left 146e8d6949db0f40cc8bc8531f8a8cb6f28dfc105f24c454cb8489ac, _ciTxOutDatum = Right (Datum {getDatum = Constr 0 []}), _ciTxOutValue = Value (Map [(,Map [(\"\",3000000)])])})]"

Everything ok up to here. Now we can execute the endpoint spend-pay that only spends this utxo and produces a new one.

  • curl -X 'POST' 'http://localhost:9080/api/contract/instance/'$CID'/endpoint/spend-pay' -H 'accept: application/json;charset=utf-8' -H 'Content-Type: application/json;charset=utf-8' --data-raw '[]'

If everything goes well again, we will see on the PAB the following message

[pab:Info:43] [2021-11-18 17:03:46.95 UTC] 555fb4ce-378b-4075-9840-5a5f684adfcd: "Calling spend and pay again endpoint."
[pab:Info:43] [2021-11-18 17:03:47.45 UTC] 555fb4ce-378b-4075-9840-5a5f684adfcd: "Operation spend and pay again submitted successfully."

Finally, if we list again the contract utxos we can see that we have more than one utxo, when we should have only one

[pab:Info:43] [2021-11-18 17:03:51.43 UTC] 555fb4ce-378b-4075-9840-5a5f684adfcd: "Calling utxos endpoint."
[pab:Info:43] [2021-11-18 17:03:51.50 UTC] 555fb4ce-378b-4075-9840-5a5f684adfcd: "Got utxos: fromList [(TxOutRef {txOutRefId = 6a5041a79715c6328e149718b3fb80b5a248bf914e392f806d221bd18cc3bc42, txOutRefIdx = 0},ScriptChainIndexTxOut {_ciTxOutAddress = Address {addressCredential = ScriptCredential 146e8d6949db0f40cc8bc8531f8a8cb6f28dfc105f24c454cb8489ac, addressStakingCredential = Nothing}, _ciTxOutValidator = Right Validator { <script> }, _ciTxOutDatum = Right (Datum {getDatum = Constr 0 []}), _ciTxOutValue = Value (Map [(,Map [(\"\",3000000)])])}),(TxOutRef {txOutRefId = 6b6463860656f738756a555ff0e575c9b65a78d067827a4d41e1d6e75389ef22, txOutRefIdx = 0},ScriptChainIndexTxOut {_ciTxOutAddress = Address {addressCredential = ScriptCredential 146e8d6949db0f40cc8bc8531f8a8cb6f28dfc105f24c454cb8489ac, addressStakingCredential = Nothing}, _ciTxOutValidator = Right Validator { <script> }, _ciTxOutDatum = Right (Datum {getDatum = Constr 0 []}), _ciTxOutValue = Value (Map [(,Map [(\"\",3000000)])])})]"

System info:

  • OS: Ubuntu
  • Version: 20.04
  • plutus: 3f089ccf0ca746b399c99afe51e063b0640af547
  • plutus-apps: 404af7a (and 7f7aca8)

Additional context

Add any other context about the problem here.
You probably should add the env variable WALLET_ID and CID.

@alegadea alegadea added the bug Something isn't working label Nov 18, 2021
@alegadea alegadea changed the title After a transaction, utxosAt returns the spent and produced utxo. After a transaction, utxosAt returns the spent and produced utxos Nov 18, 2021
@mikekeke
Copy link
Contributor

mikekeke commented Dec 6, 2021

Can confirm issue for plutus-apps 21d96e5908558a4c3b3234f6a2b63b4b6f7fdee6

@szg251
Copy link
Contributor

szg251 commented Dec 6, 2021

I experienced the same problem using the chain-index directly. These are the steps to reproduce this on the main testnet.
My plutus-apps version is 7f7aca8500105d3a0830b40627f1821c9ac7b58e.

  1. Query utxos at address:
curl --request POST --url http://localhost:9083/utxo-at-address --data '{"credential": {"tag": "PubKeyCredential", "contents": {"getPubKeyHash": "551924de3fb195c58003d753edb23cd049e0a65d0b8c33c824f0c165"}}}' --header 'Content-Type: application/json' | jq
[
  {
    "tipBlockId": "2e341cd308c7dad3f6640c8465597637e48033fd4834dd75afbda6597bc1a75a",
    "tipSlot": {
      "getSlot": 44416721
    },
    "tipBlockNo": 3131012,
    "tag": "Tip"
  },
  {
    "nextPageQuery": null,
    "pageItems": [
      {
        "txOutRefId": {
          "getTxId": "3a9e96cbb9e2399046e7b653e29e2cc27ac88b3810b15f448b91425a9a27ef3a"
        },
        "txOutRefIdx": 0
      },
      {
        "txOutRefId": {
          "getTxId": "973ef9bed0efc07d37f5565941b521bf9b44b75c71e6aab45ddd7a8a71f78efa"
        },
        "txOutRefIdx": 0
      },
      {
        "txOutRefId": {
          "getTxId": "c4a99e160c82a43c2fc127bcc971cb2ff6e62e6235424852f99ec7072890344c"
        },
        "txOutRefIdx": 0
      },
      {
        "txOutRefId": {
          "getTxId": "c4a99e160c82a43c2fc127bcc971cb2ff6e62e6235424852f99ec7072890344c"
        },
        "txOutRefIdx": 1
      },
      {
        "txOutRefId": {
          "getTxId": "e815e0ad7f131a796d7590d6969c43808863739ec9d3c6a8039f08823db526e1"
        },
        "txOutRefIdx": 0
      }
    ],
    "currentPageQuery": {
      "pageQuerySize": {
        "getPageSize": 50
      },
      "pageQueryLastItem": null
    }
  }
]
  1. Check validity of the first utxo:
curl --request POST --url http://localhost:9083/is-utxo --data '{"txOutRefId": {"getTxId": "3a9e96cbb9e2399046e7b653e29e2cc27ac88b3810b15f448b91425a9a27ef3a"}, "txOutRefIdx": 0}' --header 'Content-Type: application/json'
[
  {
    "tipBlockId": "f7ef961fdd24ae272430bb73fc0a9375c38d37a7c073c6cf4ce72815f8ef51ef",
    "tipSlot": {
      "getSlot": 44417531
    },
    "tipBlockNo": 3131042,
    "tag": "Tip"
  },
  false
]
  1. Also, I could confirm, that this utxo was used by another tx (inside the _citxInputs):
curl --request POST --url http://localhost:9083/tx --data '{"getTxId": "973ef9bed0efc07d37f5565941b521bf9b44b75c71e6aab45ddd7a8a71f78efa"}' --header 'Content-Type: application/json' | jq
{
  "_citxRedeemers": [],
  "_citxValidRange": {
    "ivTo": [
      {
        "tag": "PosInf"
      },
      true
    ],
    "ivFrom": [
      {
        "tag": "NegInf"
      },
      true
    ]
  },
  "_citxTxId": {
    "getTxId": "973ef9bed0efc07d37f5565941b521bf9b44b75c71e6aab45ddd7a8a71f78efa"
  },
  "_citxScripts": [],
  "_citxInputs": [
    {
      "txInType": null,
      "txInRef": {
        "txOutRefId": {
          "getTxId": "3a9e96cbb9e2399046e7b653e29e2cc27ac88b3810b15f448b91425a9a27ef3a"
        },
        "txOutRefIdx": 0
      }
    }
  ],
  "_citxData": [],
  "_citxCardanoTx": {
    "tx": {
      "cborHex": "84a500818258203a9e96cbb9e2399046e7b653e29e2cc27ac88b3810b15f448b91425a9a27ef3a00018282583900551924de3fb195c58003d753edb23cd049e0a65d0b8c33c824f0c165579447f60175b951df52ed3d28ba09caa2251df1bcc8f8b27195acee1a3a3944c382583900a3d0b159b730b4d28907681823a6ca155ce50f8614e00325daa85bd1da859f3b7756c74bd1f92e41928a5af7aaeddb07d89af26c757437aa1a006acfc0021a001e84800d81825820c4a99e160c82a43c2fc127bcc971cb2ff6e62e6235424852f99ec7072890344c000e80a1008182582001049effaac0a3137ebbdf5d0c02cba5bf5dc9dadda99be5b23e40f1812c0ec65840eff2947755799e2d114e7d2757519b094e236f5e9644f8b858f00cd3e1433ec0636532c696b4b39b39ee56d8c70447e32243549410642be5c0baf4d066b8bf08f5f6",
      "description": "",
      "type": "Tx AlonzoEra"
    },
    "eraInMode": "AlonzoEraInCardanoMode"
  },
  "_citxOutputs": {
    "contents": [
      {
        "txOutValue": {
          "getValue": [
            [
              {
                "unCurrencySymbol": ""
              },
              [
                [
                  {
                    "unTokenName": ""
                  },
                  976831683
                ]
              ]
            ]
          ]
        },
        "txOutAddress": {
          "addressStakingCredential": {
            "contents": {
              "contents": {
                "getPubKeyHash": "579447f60175b951df52ed3d28ba09caa2251df1bcc8f8b27195acee"
              },
              "tag": "PubKeyCredential"
            },
            "tag": "StakingHash"
          },
          "addressCredential": {
            "contents": {
              "getPubKeyHash": "551924de3fb195c58003d753edb23cd049e0a65d0b8c33c824f0c165"
            },
            "tag": "PubKeyCredential"
          }
        },
        "txOutDatumHash": null
      },
      {
        "txOutValue": {
          "getValue": [
            [
              {
                "unCurrencySymbol": ""
              },
              [
                [
                  {
                    "unTokenName": ""
                  },
                  7000000
                ]
              ]
            ]
          ]
        },
        "txOutAddress": {
          "addressStakingCredential": {
            "contents": {
              "contents": {
                "getPubKeyHash": "da859f3b7756c74bd1f92e41928a5af7aaeddb07d89af26c757437aa"
              },
              "tag": "PubKeyCredential"
            },
            "tag": "StakingHash"
          },
          "addressCredential": {
            "contents": {
              "getPubKeyHash": "a3d0b159b730b4d28907681823a6ca155ce50f8614e00325daa85bd1"
            },
            "tag": "PubKeyCredential"
          }
        },
        "txOutDatumHash": null
      }
    ],
    "tag": "ValidTx"
  }
}

@ghost ghost self-assigned this Dec 9, 2021
@ghost
Copy link

ghost commented Dec 9, 2021

Thanks for reporting the issue! And thanks @gege251 for the provided steps!

We have located the issue and the fix is in progress.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants