TransactionsService.getTransactionUTxOs doesn't return dataHash or inlineDatum values

[satran004]

What operating system are you using, and which version?

• [ ] Linux / Ubuntu
• [ ] Linux / Other
• [x] OSX
• [ ] Windows

Steps to Reproduce

• Invoke TransactionsService.getTransactionUTxOs() with the following tx_hash and check TxUtxo.getOutputs() 33383bfecb9e541d32857eda88b18ffc71943372fe8ae7b4792589b72a41e26e

Expected Behavior

The output (TxIO) at txIndex = 2 should have

dataHash = 4194bb3c4c0fd47485112d09ea85b2dd6ab44fa826b77cbf9ed0f12582b057d9 InlineDatum = d87a9fd8799fd8799f581cd1707e481671d473ee5a8d561aaac4a1f4e8c937ce61e5d11fc0611fffd8799fd8799f1a000687241b00000187a8d155a2ffffffff

Actual Behavior

dataHash and inlineDatum are null.

Similarly for another transaction TxHash: d8109586a0dfb1bdc62bec0e6b41f3825994380f32ecad609792587ed3080d10 Output Index: 0

ReferenceScript is null, but the expected reference script hash = b010c0888e93aa488d941ba4839136fceb9b9a9ec310a573299286d7

[edridudi]

@rdlrt, looks like Koios instance does not return the dataHash and inlineDatum for the specified UTxO.

{
    "value":"2000000",
    "tx_hash":"33383bfecb9e541d32857eda88b18ffc71943372fe8ae7b4792589b72a41e26e",
    "tx_index":2,
    "asset_list":[
       {
          "decimals":0,
          "quantity":"1",
          "policy_id":"531f40858e47ffb9935b5abd5e995e7d3bb44423b4f3fae1121c0299",
          "asset_name":"4e6f646546656564",
          "fingerprint":"asset1v8lglf9kmwl8mq3v4mv590z3skq2ka3zzwe7hd"
       },
       {
          "decimals":0,
          "quantity":"244200",
          "policy_id":"436941ead56c61dbf9b92b5f566f7d5b9cac08f8c957f28f0bd60d4b",
          "asset_name":"5041594d454e54544f4b454e",
          "fingerprint":"asset1hdfatxyf7mn8x5rutgy5ehgxpsqxx3un9alm88"
       }
    ],
    "stake_addr":null,
    "payment_addr":{
       "cred":"791d504ef072be11979a3c722bf1a46a8af77be7326fb7949da497c1",
       "bech32":"addr_test1wpu365zw7petuyvhng78y2l3534g4ammuuexldu5nkjf0sgz5xu88"
    }
 }

Can you please check that?

[rdlrt]

@edridudi @satran004 - Just to be 100% sure that we're aligned, the issue is only with tx_utxos endpoint correct? Will be good to maybe discuss it once.

For background, the issue is that we reused the specs for tx_utxos using fields from tx_info endpoint (see here ). The original intention for tx_utxos was to simply provide a brief (quick) info about the transaction outputs involved, with corresponding value/asset amounts, while it's sibling endpoint tx_info to give full fledged [as much info as available] being less performant. This was useful specifically for wallets and NFT marketplaces.

Thus , we never really accounted for datum/inline_datum/reference scripts on tx_utxos (datum_hash has almost neglible impact , but other two adds a join) - but I understand if that's an issue, especially now with solution(s) implemented on it. With that background shared, can I check quickly with you if we should add these fields to tx_utxos OR address specs accordingly?

[edridudi]

@rdlrt I think it's only logical to retrieve all tx utxos data (only) from the tx utxos endpoint. maybe it's worth mentioning that tx info and address info shouldn't output utxos and maybe for address service to introduce another endpoint just for UTxOs.

I understand it can be trouble due to breaking changes but for Libraries like CCL or Lucid that introduce multiple providers, it is best to have their models aligned as best as can.

[edridudi]

@satran004 , Eventually, it is decided to use tx_info as a full information endpoint about a specific Tx, Hence code should be changed in CCL.

the issue is resolved with this PR in CCL: https://github.com/bloxbean/cardano-client-lib/pull/246

Thank you @rdlrt

[rdlrt]

Hey @edridudi haven't completed the decision yet, can we leave open until Tuesday? The main contention there is presence of asset_list in output (as other fields are part of tx_out itself, atleast to provide a primary key - they dont impact Performance as much) for address/accounts/creds, we'd need to experiment a bit, especially since we create JSONB child field which isnt paginated

[edridudi]

Sure.