Explorer should show transaction/receipts executed on the given account

[evgenykuzyakov]

Story

As a user I want to see transactions/receipts that touch a given contract as a receiver. E.g. if I go to the https://explorer.nearprotocol.com/accounts/chatbot the explorer only shows the transactions issued by this account and transactions where the given account is direct receiver, but doesn't show the other contracts calling this contract (cross-contract calls).

Background for chatbot:

• chatbot implements post_message calls for metanear user-centric standard and reacts to the received messages by calling other contracts with post_message as well.

[frol]

It should work as described, so if it does not, it is a bug.

[icerove]

@evgenykuzyakov where can I use that chatbot so I can test whether it is okay? also you can see corgis https://explorer.nearprotocol.com/accounts/new-corgis if this is the txs you described

[frol]

@evgenykuzyakov All the 9 transactions are presented in the UI: 8 of them are incoming and outcoming at the same time (the receiver and the signer are chatbot).

[evgenykuzyakov]

Ok. I think I know what's going on. If a receipts touches the contract, then the transaction is not displayed.

[frol]

@evgenykuzyakov can you provide a link / a transaction hash which you expect to see on the list, but it is not there?

[evgenykuzyakov]

Updated the title and the story

[evgenykuzyakov]

Transaction: https://explorer.nearprotocol.com/transactions/AfuMwwEDcboZr5vuYqmGkVTNPRBhNa8ZunjpbardrBTo

TxStatus:

$ near tx-status --account_id=eugenethedream AfuMwwEDcboZr5vuYqmGkVTNPRBhNa8ZunjpbardrBTo                                                              

{
  receipts_outcome: [
    {
      block_hash: 'AoDCGdhWn838B1WS34vNhbC2XtuRcNKfyuwGTzoD6s9j',
      id: '4iqrVqAJsvma5dLiCsqBQYU4vzYBQ8B1j584XhDXnaCs',
      outcome: {
        gas_burnt: 5330224579527,
        logs: [],
        receipt_ids: [
          '7q9rYMZED6uwDwtdCrbPBfWoPdbJ46GVWMrsafab94kJ',
          '43LCjRwowyi6u7eMHXhYM5c7ZG3JZWZeyrt5aL3Rtx1e'
        ],
        status: {
          SuccessReceiptId: '7q9rYMZED6uwDwtdCrbPBfWoPdbJ46GVWMrsafab94kJ'
        }
      },
      proof: [
        {
          direction: 'Left',
          hash: 'DpFyDzBMkxgCYhP7H6iXEHA9T8Dg8qiRv9xg1gEsE21B'
        }
      ]
    },
    {
      block_hash: 'CsL5dzSmrdZTbxWDNgMVNPHNXzkGXPkntve79P4jUtqW',
      id: '7q9rYMZED6uwDwtdCrbPBfWoPdbJ46GVWMrsafab94kJ',
      outcome: {
        gas_burnt: 5480660706643,
        logs: [],
        receipt_ids: [
          'G73xbY7y9yFifrATKKwEjwxRuoJbRPU21L6USA1tLvec',
          'F9G8sGxrWdRd5EcxEPvResHeYwqU9qfLN1XR5KpsYZHC'
        ],
        status: { SuccessValue: '' }
      },
      proof: []
    },
    {
      block_hash: 'Hkh5VVuXd1Su1pZsXcWgJj3zp8ZL76mGFtaMBueBZxgb',
      id: 'G73xbY7y9yFifrATKKwEjwxRuoJbRPU21L6USA1tLvec',
      outcome: {
        gas_burnt: 3130521261082,
        logs: [],
        receipt_ids: [ 'AA1yu39GHuLVbzCiL2oM2Hs2kDEbHaC5mcXW7YUT8Dbb' ],
        status: { SuccessValue: '' }
      },
      proof: [
        {
          direction: 'Right',
          hash: '33hcwCq6eWp9Rt3aFh7eKnFAsdJjTauLu7bDKHaCSqof'
        }
      ]
    },
    {
      block_hash: '2aFk7m5tk768EKTKFMT2uJRG42ZdrLZBP9LNoG1dizag',
      id: 'AA1yu39GHuLVbzCiL2oM2Hs2kDEbHaC5mcXW7YUT8Dbb',
      outcome: {
        gas_burnt: 0,
        logs: [],
        receipt_ids: [],
        status: { SuccessValue: '' }
      },
      proof: []
    },
    {
      block_hash: 'Hkh5VVuXd1Su1pZsXcWgJj3zp8ZL76mGFtaMBueBZxgb',
      id: 'F9G8sGxrWdRd5EcxEPvResHeYwqU9qfLN1XR5KpsYZHC',
      outcome: {
        gas_burnt: 0,
        logs: [],
        receipt_ids: [],
        status: { SuccessValue: '' }
      },
      proof: [
        {
          direction: 'Left',
          hash: 'FjkafWUmEo8hXCi81WCvQJ8Gu4bjyiYjo16ogLbr9STE'
        }
      ]
    },
    {
      block_hash: 'CsL5dzSmrdZTbxWDNgMVNPHNXzkGXPkntve79P4jUtqW',
      id: '43LCjRwowyi6u7eMHXhYM5c7ZG3JZWZeyrt5aL3Rtx1e',
      outcome: {
        gas_burnt: 0,
        logs: [],
        receipt_ids: [],
        status: { SuccessValue: '' }
      },
      proof: []
    }
  ],
  status: { SuccessValue: '' },
  transaction: {
    actions: [
      {
        FunctionCall: {
          args: 'eyJyZWNlaXZlcl9pZCI6ImNoYXRib3QiLCJhcHBfaWQiOiJtYWlsIiwibWVzc2FnZSI6IntcInR5cGVcIjpcIm1haWxcIixcInN1YmplY3RcIjpcIkhlbGxvLCBteSBodW1hbiBmcmllbmQhXCIsXCJjb250ZW50XCI6XCJcIn0ifQ==',
          deposit: '0',
          gas: 2000000000000000,
          method_name: 'send_message'
        }
      }
    ],
    hash: 'AfuMwwEDcboZr5vuYqmGkVTNPRBhNa8ZunjpbardrBTo',
    nonce: 78,
    public_key: 'ed25519:KuTCtARNzxZQ3YvXDeLjx83FDqxv2SdQTSbiq876zR7',
    receiver_id: 'eugenethedream',
    signature: 'ed25519:2UqMvDPJHjc34T5yX6ZSbXcwSKuk6H1EJ97hm68o54myooso2kvRqcVAFMA4zXou4twPK79XrjeGpfnATyTKrHk3',
    signer_id: 'eugenethedream'
  },
  transaction_outcome: {
    block_hash: 'AoDCGdhWn838B1WS34vNhbC2XtuRcNKfyuwGTzoD6s9j',
    id: 'AfuMwwEDcboZr5vuYqmGkVTNPRBhNa8ZunjpbardrBTo',
    outcome: {
      gas_burnt: 2291826403326,
      logs: [],
      receipt_ids: [ '4iqrVqAJsvma5dLiCsqBQYU4vzYBQ8B1j584XhDXnaCs' ],
      status: {
        SuccessReceiptId: '4iqrVqAJsvma5dLiCsqBQYU4vzYBQ8B1j584XhDXnaCs'
      }
    },
    proof: [
      {
        direction: 'Right',
        hash: '2djfrWrNqR2aCbMoAshMruao6vsoDv7k2fTzCmqFNqzv'
      }
    ]
  }
}

[frol]

@evgenykuzyakov Since I don't see any chatbot reference, it seems that we should expose some extra info from nearcore RPC first... I assume we should expose receipts as they hold the information about receiver. Does this sound right to you?

[evgenykuzyakov]

Yes. This sounds reasonable. We should be able to query receipts

[frol]

Well, even though we don't have the API to query the individual receipts in nearcore, we don't need that to implement this. We need to index the receipts into Explorer DB, so this issue is blocked on https://github.com/nearprotocol/near-explorer/issues/218

[frol]

@SkidanovAlex @evgenykuzyakov @chain-police We need your knowledge about receipts and execution outcomes!

Is there a place where we can learn about all the corner cases of transaction lifetime?

I can list a few concerns:

1. Is there a way to match actions to the execution outcomes? @nearmax says that execution outcome is only relevant to the last action on a receipt.
2. What is expected to happen when a single transaction/receipt has more than one FunctionCall actions? Will the logs get combined? Will the cross-contract calls get executed?
3. Can we define a transaction status in a meaningful way? @nearmax suggested we only have "in-progress" and "completed" (when all the receipts are resolved) /cc @kcole16 @icerove @corwinharrell

Correct me if I am wrong at any place:

1. We receive a transaction for inclusion into a chain; it is signed and usually submitted via JSON RPC
2. The transaction gets pre-validated and may even not included in the mempool (we don't observe it in Explorer)
3. Eventually, the transaction will get included in some chunk / block (we will observe the transaction with actions in a chunk)
4. The network gets to transaction conversion in a later [the next?] block after it was included, and we can observe an ExecutionOutcome referencing a receipt, that will get executed (it seems that we cannot assume that the receipt itself will get included in the same block as the Execution Outcome, right?)
5. Some blocks later the receipt will get executed and will have its ExecutionOutcome; if the ExecutionOutcome references any receipts, we should keep following those in the next blocks, otherwise, we check if it was the last ExecutionOutcome for the given transaction (we have to keep track of it), and mark the transaction as "complete", right?

Thus, there are at least 3 blocks involved from transaction submission to the final receipt ExecutionOutcome?

1. transaction
2. transaction ExecutionOutcome + receipt
3. receipt ExecutionOutcome

/cc @mikedotexe @amgando @vgrichina @khorolets

[bowenwang1996]

The network gets to transaction conversion in a later [the next?] block after it was included, and we can observe an ExecutionOutcome referencing a receipt, that will get executed (it seems that we cannot assume that the receipt itself will get included in the same block as the Execution Outcome, right?)

It happens in the same block (when the transaction is applied).

Some blocks later the receipt will get executed and will have its ExecutionOutcome; if the ExecutionOutcome references any receipts, we should keep following those in the next blocks, otherwise, we check if it was the last ExecutionOutcome for the given transaction (we have to keep track of it), and mark the transaction as "complete", right?

Right, but note that the tx_status rpc will not wait for all receipts to complete before returning, so you might need to do some polling on explorer side.

Thus, there are at least 3 blocks involved from transaction submission to the final receipt ExecutionOutcome?

As I said above, transaction is converted to receipt after it is applied (in the same block).

[icerove]

Need maybe a presentation from runtime team to understand these things better, especially about receipts result and relation. I want to understand the mechanism not every details. @nearmax @evgenykuzyakov @bowenwang1996 @frol @khorolets

[MaksymZavershynskyi]

@evgenykuzyakov we have a dire need for a full runtime spec.