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

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

Open
leighmcculloch opened this issue Nov 17, 2023 · 5 comments
Assignees
Labels
bug Something isn't working stale

Comments

@leighmcculloch
Copy link
Member

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.

@leighmcculloch leighmcculloch added the bug Something isn't working label Nov 17, 2023
@willemneal
Copy link
Member

Will include in #1065

@mollykarcher mollykarcher moved this from Backlog to Current Sprint in Platform Scrum Dec 21, 2023
@mollykarcher mollykarcher moved this from Current Sprint to Next Sprint Proposal in Platform Scrum Dec 21, 2023
@mollykarcher mollykarcher added this to the Soroban Pubnet Release milestone Dec 21, 2023
@2opremio
Copy link
Contributor

2opremio commented Jan 8, 2024

I should be possible to include diagnostic events after #1152

@willemneal would you please take a look?

@2opremio
Copy link
Contributor

2opremio commented Jan 9, 2024

For extra context, we would really like to have this before the pubnet release.

@2opremio
Copy link
Contributor

@willemneal any updates? We want this before the pubnet release

Copy link
Contributor

github-actions bot commented Dec 8, 2024

This issue is stale because it has been assigned for 30 days with no activity. It will be closed in 30 days unless the stale label is removed, and the assignee is removed or updated.

@github-actions github-actions bot added the stale label Dec 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working stale
Projects
Status: Backlog (Not Ready)
4 participants