SC: if there is no uco_transfer, the contract cannot create a new tx

[bchamagne]

Describe the problem you discovered

Here is a pretty plain contract:

condition inherit: [
	content: true
]

condition transaction: [
	uco_transfers: size() > 0
]

actions triggered_by: transaction do
	set_content "hello"
end

It just creates a new tx with content = "hello" when we send it ucos.
This contract will fail with this error :

2023-01-18 14:02:44.862 transaction_address=0000605AC1B17EFFE93BE96C5EF1B37A8C5E252F23CFF31D229E0E9359D16882FF91 transaction_type=transfer [debug] Previous transaction %Archethic.TransactionChain.Transaction{address: <<0, 0, 34, 35, 187, 212, 236, 61, 100, 174, 89, 118, 150, 199, 215, 173, 225, 206, 230, 92, 99, 157, 136, 84, 80, 173, 45, 123, 117, 89, 42, 199, 106, 250>>, type: :contract, data: %Archethic.TransactionChain.TransactionData{recipients: [], ledger: %Archethic.TransactionChain.TransactionData.Ledger{uco: %Archethic.TransactionChain.TransactionData.UCOLedger{transfers: []}, token: %Archethic.TransactionChain.TransactionData.TokenLedger{transfers: []}}, code: "condition inherit: [\n\tcontent: true\n]\n\ncondition transaction: [\n\tuco_transfers: size() > 0\n]\n\nactions triggered_by: transaction do\n\tset_content \"hello\"\nend", ownerships: [%Archethic.TransactionChain.TransactionData.Ownership{authorized_keys: %{<<0, 1, 116, 101, 5, 78, 217, 64, 182, 67, 248, 163, 18, 183, 225, 130, 58, 241, 75, 223, 222, 250, 220, 78, 111, 19, 91, 2, 10, 19, 29, 120, 5, 4>> => <<154, 168, 236, 235, 106, 168, 17, 117, 15, 104, 252, 43, 49, 158, 177, 91, 110, 209, 139, 77, 194, 104, 254, 181, 197, 52, 33, 148, 74, 4, 176, 71, 38, 168, 199, 116, 44, 120, 135, 234, ...>>}, secret: <<75, 144, 132, 173, 238, 225, 243, 156, 185, 129, 106, 23, 58, 95, 195, 49, 86, 93, 135, 135, 166, 128, 178, 218, 11, 164, 23, 63, 86, 242, 173>>}], content: ""}, previous_public_key: <<0, 1, 96, 219, 187, 26, 208, 67, 32, 203, 208, 231, 88, 221, 76, 158, 202, 164, 178, 44, 145, 33, 162, 27, 6, 198, 73, 8, 15, 206, 179, 120, 68, 211>>, previous_signature: <<115, 42, 136, 45, 80, 50, 29, 38, 53, 124, 199, 180, 235, 89, 10, 82, 77, 158, 163, 123, 4, 210, 139, 127, 5, 195, 223, 125, 27, 31, 232, 42, 119, 47, 7, 69, 105, 189, 237, 3, 168, 235, 133, 36, 205, ...>>, origin_signature: <<48, 68, 2, 32, 89, 62, 30, 4, 105, 51, 219, 23, 190, 36, 188, 30, 112, 92, 75, 7, 166, 224, 192, 125, 55, 123, 183, 30, 27, 89, 55, 175, 91, 89, 37, 18, 2, 32, 49, 166, 64, 149, 93, 22, ...>>, validation_stamp: %Archethic.TransactionChain.Transaction.ValidationStamp{protocol_version: 1, timestamp: ~U[2023-01-18 14:01:55.038Z], signature: <<32, 210, 33, 48, 235, 103, 162, 146, 214, 78, 233, 161, 139, 138, 251, 129, 205, 128, 2, 36, 249, 17, 22, 6, 250, 103, 243, 86, 85, 4, 33, 172, 183, 154, 253, 88, 234, 57, 166, 11, ...>>, proof_of_work: <<1, 1, 4, 171, 65, 41, 31, 132, 122, 96, 16, 85, 174, 221, 26, 242, 79, 247, 111, 169, 112, 214, 68, 30, 45, 202, 56, 24, 168, 49, 155, 0, 76, 150, 178, 123, 143, 235, 29, ...>>, proof_of_integrity: <<0, 128, 96, 77, 173, 135, 247, 219, 91, 100, 253, 150, 143, 67, 156, 192, 22, 132, 162, 97, 59, 2, 162, 154, 195, 250, 179, 255, 34, 38, 247, 34, 25>>, proof_of_election: <<41, 195, 107, 219, 147, 107, 230, 29, 38, 162, 30, 7, 20, 79, 253, 201, 245, 158, 32, 100, 212, 67, 138, 189, 216, 64, 109, 62, 47, 179, 252, 235, 149, 201, 10, 0, 48, ...>>, ledger_operations: %Archethic.TransactionChain.Transaction.ValidationStamp.LedgerOperations{transaction_movements: [], unspent_outputs: [%Archethic.TransactionChain.Transaction.ValidationStamp.LedgerOperations.UnspentOutput{amount: 9989407353, from: <<0, 0, 34, 35, 187, 212, 236, 61, 100, 174, 89, 118, 150, 199, 215, 173, 225, 206, 230, 92, 99, 157, 136, 84, 80, 173, 45, 123, 117, 89, 42, ...>>, type: :UCO, timestamp: ~U[2023-01-18 14:01:55.038Z], reward?: false}], fee: 10592647}, recipients: [], error: nil}, cross_validation_stamps: [%Archethic.TransactionChain.Transaction.CrossValidationStamp{node_public_key: <<0, 1, 29, 150, 125, 113, 178, 225, 53, 200, 66, 6, 221, 209, 8, 181, 146, 90, 44, 217, 156, 142, 188, 90, 181, 216, 253, 46, 201, 64, 12, 227, 201, 138>>, signature: <<10, 9, 118, 132, 161, 201, 20, 123, 119, 240, 56, 142, 110, 76, 127, 70, 240, 100, 167, 51, 74, 253, 42, 79, 171, 166, 44, 196, 190, 86, 143, 43, 187, 35, 195, 121, 82, 141, 39, ...>>, inconsistencies: []}], version: 1}
2023-01-18 14:02:44.866 transaction_address=0000605AC1B17EFFE93BE96C5EF1B37A8C5E252F23CFF31D229E0E9359D16882FF91 transaction_type=transfer [info] Contains errors: :invalid_pending_transaction
2023-01-18 14:02:44.866 [info] KO transaction 0000605AC1B17EFFE93BE96C5EF1B37A8C5E252F23CFF31D229E0E9359D16882FF91
2023-01-18 14:02:44.866 transaction_address=0000605AC1B17EFFE93BE96C5EF1B37A8C5E252F23CFF31D229E0E9359D16882FF91 transaction_type=transfer [warning] Invalid transaction for replication - :invalid_pending_transaction
2023-01-18 14:02:44.866 transaction_address=0000605AC1B17EFFE93BE96C5EF1B37A8C5E252F23CFF31D229E0E9359D16882FF91 [warning] Invalid transaction :invalid_pending_transaction

Describe the solution you'd like

It's probably because of that transaction_type=transfer we can see in the logs

[samuelmanzanera]

I think you can use the type "contract" by default, as the new transaction will always contain the previous code or another one

[samuelmanzanera]

We could also check in the parser if there is not a set_type instruction any action blocks to enforce the transaction's type