soroban-cli: doesn't output diagnostic logs received from submitting tx that fails

Open
#1,089 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

  • #1065 by @willemneal — closed without merging

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
30/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
cli

Research direction

Start at the soroban-cli transaction submission path, especially the --very-verbose handling of the submission /tx endpoint response, and compare it with simulation diagnostics. Reproduce the TxSorobanInvalid case and verify that diagnostic events from the submission response are shown to the user.

Written by the indexing model from the issue text.

Description

bug
What version are you using?
soroban 20.0.0-rc4 (bce5e56ba16ba977200b022c91f3eaf6282f47eb)

Ref: https://discord.com/channels/897514728459468821/966788672164855829/1174863875229892708

What did you do?

Submitted tx that passes simulation fine but fails immediately with TxSorobanInvalid when submitted. Running soroban-cli with --very-verbose mode.

What did you expect to see?

Diagnostic logs about why the TxSorobanInvalid error occurred. Diagnostic events are outputted for the simulation, but not for the submission, even though stellar-core provides these on the submission /tx endpoint.

What did you see instead?

No diagnostic events/logs on the submission.

2023-11-17T00:07:24.589909Z TRACE soroban_cli::rpc: tx=Tx(TransactionV1Envelope { tx: Transaction { source_account: Ed25519(Uint256(65c82c58146503d36ba4afdf3d6f6e8c5552480d98d96cf9eb25c02a786328ac)), fee: 2338115, seq_num: SequenceNumber(10985628695003150), cond: None, memo: None, operations: VecM([Operation { source_account: None, body: InvokeHostFunction(InvokeHostFunctionOp { host_function: InvokeContract(InvokeContractArgs { contract_address: Contract(Hash(3e38f3acdd8d62db6e60908301b3d1b8ed0ac2bb42ffddab23eba7c21a330bb6)), function_name: ScSymbol(StringM(remove_liquidity)), args: VecM([Address(Contract(Hash(c4bfe449c9e8dfd0553d4f6a50da7a51b22f487c15429aa91738dce4b2579723))), Address(Contract(Hash(0650d515bbe2aebd9168e2f861b49784568af45c613a341920162828f50ecaca))), I128(Int128Parts { hi: 0, lo: 9999999000 }), I128(Int128Parts { hi: 0, lo: 0 }), I128(Int128Parts { hi: 0, lo: 0 }), Address(Account(AccountId(PublicKeyTypeEd25519(Uint256(65c82c58146503d36ba4afdf3d6f6e8c5552480d98d96cf9eb25c02a786328ac))))), U64(9737055687)]) }), auth: VecM([SorobanAuthorizationEntry { credentials: SourceAccount, root_invocation: SorobanAuthorizedInvocation { function: ContractFn(InvokeContractArgs { contract_address: Contract(Hash(3e38f3acdd8d62db6e60908301b3d1b8ed0ac2bb42ffddab23eba7c21a330bb6)), function_name: ScSymbol(StringM(remove_liquidity)), args: VecM([Address(Contract(Hash(c4bfe449c9e8dfd0553d4f6a50da7a51b22f487c15429aa91738dce4b2579723))), Address(Contract(Hash(0650d515bbe2aebd9168e2f861b49784568af45c613a341920162828f50ecaca))), I128(Int128Parts { hi: 0, lo: 9999999000 }), I128(Int128Parts { hi: 0, lo: 0 }), I128(Int128Parts { hi: 0, lo: 0 }), Address(Account(AccountId(PublicKeyTypeEd25519(Uint256(65c82c58146503d36ba4afdf3d6f6e8c5552480d98d96cf9eb25c02a786328ac))))), U64(9737055687)]) }), sub_invocations: VecM([SorobanAuthorizedInvocation { function: ContractFn(InvokeContractArgs { contract_address: Contract(Hash(8754aaaad15fb907d6534beaa15985765a1b5dfbb690b655ede2d71d336ecc51)), function_name: ScSymbol(StringM(transfer)), args: VecM([Address(Account(AccountId(PublicKeyTypeEd25519(Uint256(65c82c58146503d36ba4afdf3d6f6e8c5552480d98d96cf9eb25c02a786328ac))))), Address(Contract(Hash(8754aaaad15fb907d6534beaa15985765a1b5dfbb690b655ede2d71d336ecc51))), I128(Int128Parts { hi: 0, lo: 9999999000 })]) }), sub_invocations: VecM([]) }]) } }]) }) }]), ext: V1(SorobanTransactionData { ext: V0, resources: SorobanResources { footprint: LedgerFootprint { read_only: VecM([ContractData(LedgerKeyContractData { contract: Contract(Hash(0650d515bbe2aebd9168e2f861b49784568af45c613a341920162828f50ecaca)), key: LedgerKeyContractInstance, durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(3e38f3acdd8d62db6e60908301b3d1b8ed0ac2bb42ffddab23eba7c21a330bb6)), key: LedgerKeyContractInstance, durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(a6ae14e68f2317a65f8e16e3ba98a342753d59041b8d40f8fb5668711e478309)), key: LedgerKeyContractInstance, durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(c4bfe449c9e8dfd0553d4f6a50da7a51b22f487c15429aa91738dce4b2579723)), key: LedgerKeyContractInstance, durability: Persistent }), ContractCode(LedgerKeyContractCode { hash: Hash(3898f6eb84a1eaf3600024196a29ae77bceb8f750b0682e75cf89f3bc73469d6) }), ContractCode(LedgerKeyContractCode { hash: Hash(9842c7a34cc0c8121f0587d699ed5debf5327be9f8bfdca554a9b80c3036d762) }), ContractCode(LedgerKeyContractCode { hash: Hash(e52c1c9c9c0db89b0a054417474523f281aea799672604664804ed9051e0e24f) }), ContractCode(LedgerKeyContractCode { hash: Hash(efbbdccfb3e45c395962c3014745623dc2f1638e9ef5eccb993988f43c8fb70f) })]), read_write: VecM([ContractData(LedgerKeyContractData { contract: Contract(Hash(0650d515bbe2aebd9168e2f861b49784568af45c613a341920162828f50ecaca)), key: Vec(Some(ScVec(VecM([Symbol(ScSymbol(StringM(Balance))), Address(Account(AccountId(PublicKeyTypeEd25519(Uint256(65c82c58146503d36ba4afdf3d6f6e8c5552480d98d96cf9eb25c02a786328ac)))))])))), durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(0650d515bbe2aebd9168e2f861b49784568af45c613a341920162828f50ecaca)), key: Vec(Some(ScVec(VecM([Symbol(ScSymbol(StringM(Balance))), Address(Contract(Hash(8754aaaad15fb907d6534beaa15985765a1b5dfbb690b655ede2d71d336ecc51)))])))), durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(8754aaaad15fb907d6534beaa15985765a1b5dfbb690b655ede2d71d336ecc51)), key: Vec(Some(ScVec(VecM([Symbol(ScSymbol(StringM(Balance))), Address(Account(AccountId(PublicKeyTypeEd25519(Uint256(65c82c58146503d36ba4afdf3d6f6e8c5552480d98d96cf9eb25c02a786328ac)))))])))), durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(8754aaaad15fb907d6534beaa15985765a1b5dfbb690b655ede2d71d336ecc51)), key: Vec(Some(ScVec(VecM([Symbol(ScSymbol(StringM(Balance))), Address(Contract(Hash(8754aaaad15fb907d6534beaa15985765a1b5dfbb690b655ede2d71d336ecc51)))])))), durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(8754aaaad15fb907d6534beaa15985765a1b5dfbb690b655ede2d71d336ecc51)), key: LedgerKeyContractInstance, durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(c4bfe449c9e8dfd0553d4f6a50da7a51b22f487c15429aa91738dce4b2579723)), key: Vec(Some(ScVec(VecM([Symbol(ScSymbol(StringM(Balance))), Address(Account(AccountId(PublicKeyTypeEd25519(Uint256(65c82c58146503d36ba4afdf3d6f6e8c5552480d98d96cf9eb25c02a786328ac)))))])))), durability: Persistent }), ContractData(LedgerKeyContractData { contract: Contract(Hash(c4bfe449c9e8dfd0553d4f6a50da7a51b22f487c15429aa91738dce4b2579723)), key: Vec(Some(ScVec(VecM([Symbol(ScSymbol(StringM(Balance))), Address(Contract(Hash(8754aaaad15fb907d6534beaa15985765a1b5dfbb690b655ede2d71d336ecc51)))])))), durability: Persistent })]) }, instructions: 101271949, read_bytes: 64548, write_bytes: 1484 }, refundable_fee: 5735 }) }, signatures: VecM([DecoratedSignature { hint: SignatureHint(786328ac), signature: Signature(BytesM(f7110432580da8bfa20296f6cd3cecd7af159859b514e7b4f7d006eb975dfda06772c35f02d139d8e65bf4bf20b03bf0fd016654da1270195ab0e93386b49d0b)) }]) })
2023-11-17T00:07:24.908384Z ERROR soroban_cli::rpc: error=Ok(TxSorobanInvalid)
error: transaction submission failed: TxSorobanInvalid

Full logs: https://discord.com/channels/897514728459468821/966788672164855829/1174863666252877834

Discussion

It is possible this is a bug in the RPC, unclear.

I'm not actually sure which stellar-core the submission occurs through, but if it occurs through the soroban-rpc's stellar-core which has diagnostic logs enabled (as evidenced by the diagnostic events visible during simulation), the immediate error response from stellar-core should have diagnostic logs according to @dmkozh.

Dominant language
Rust
Stars
123
Forks
141
Avg merge
2d 21h
Merged PRs (30d)
17

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from stellar/stellar-cli

All issues in stellar/stellar-cli

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.