Replies: 3 comments 5 replies
-
This doesn't sound like a downcasting issue. It sounds like an error much earlier in the evaluation - the node trying to deserialize either the contract you passed or the datum, either of which are not passed in the correct format. Please add the blockfrost/pycardano code trying to spend the transaction, otherwise it is impossible to find the issue. |
Beta Was this translation helpful? Give feedback.
-
It looks like this is an issue with the cardano-submit-api (which is used by @blockfrost) A related issue has been raised here: IntersectMBO/cardano-node#4829 You might want to try instead using the Ogmios backend offered by @Python-Cardano |
Beta Was this translation helpful? Give feedback.
-
This might also be an issue with using the wrong addresses. A common mistake during submission and its resolution was posted here:Python-Cardano/pycardano#165 (comment) |
Beta Was this translation helpful? Give feedback.
-
https://preprod.cexplorer.io/tx/77b502b5b33318fb9b5524efdf7533f14e152d283e3a7b7d098393a99cd165f1
The datum subbmited in the above transaction renders as:
which was submitted to the contract as
winnerDetails = winnerList([winner(winner1hash,20000000)])
Where winner list is
The contract compiles and uses the following function to downcast the Datum into the correct type
After being cast a for loop will iterate over the datum
Trying to spend a UTXO @ the contract results in an error RawCborDecodeError -- Size mismatch when decoding TxAux.\\nExpected 2, but found 4.\"),DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 1 \"Size mismatch when decoding \\nRecord RecD.....
After casting are the custom class and the datum equivalent ?
What is the best way to debugg these types of errors in eopsin - can the eopsin eval command be used to verify the down cast of type?
Beta Was this translation helpful? Give feedback.
All reactions