RPC for querying receipts

[ilblackdragon]

Getting timeout errors while fetching tx-status of the receipt when using a single node setup on localhost.

$ near tx-status test.near:ADFm3ULGtbFycZzQXaTXogb2qDbAtW6CEtW7SgkJaHEm
Error:  TypedError: [-32000] Server error: Timeout error
    at JsonRpcProvider.sendJsonRpc (/usr/local/lib/node_modules/near-shell/node_modules/near-api-js/lib/providers/json-rpc-provider.js:157:27)
    at processTicksAndRejections (internal/process/task_queues.js:94:5)
    at async /usr/local/lib/node_modules/near-shell/commands/tx-status.js:33:24
    at async Object.handler (/usr/local/lib/node_modules/near-shell/utils/exit-on-error.js:37:9) {
  type: 'UntypedError'
}

Steps to reproduce

1. Send some transaction that has receipts (function calls / transfers)
2. Find the receipt ID
3. Call near tx-status <account_id>:<receipt_hash>

Observe timeout error.

Expected:

• Either "not found" error
• Or receipt info

[bowenwang1996]

We disabled receipt query long ago. The issue here is that a node cannot distinguish just from the hash whether you intend to query transaction or receipt and it assumes that you are trying to query a transaction.

[frol]

Should this be transformed into an issue of adding an API for fetching Receipt status (execution outcome)?

[bowenwang1996]

According to @abacabadabacaba, it is now needed for the bridge to work. Let's prioritize this

[frol]

What data is needed? Receipt or execution outcome, or both?

[bowenwang1996]

@abacabadabacaba please clarify.

[abacabadabacaba]

For the bridge, the receipt itself is needed (specifically, which functions were called, as well as the arguments).

[alexauroradev]

@Kouprin , is this something that needs to be done to enable #3658 ? You managed to do it somehow, don't you?

The background is outlined in the Near-One/rainbow-bridge#432 . In short here're the steps that we would like to reproduce:

1. A user sends a transaction to token connector on NEAR. This transaction produces execution outcome.
2. This execution outcome is requested from NEAR in a provable format, ...
3. To send it to Ethereum contract to get tokens on Ethereum side.

Now, there should be an ability to do the step 2, having all the necessary info from the first transaction.

@Kouprin , can you please comment whether this is something that can be achieved at the moment?

[bowenwang1996]

Now, there should be an ability to do the step 2, having all the necessary info from the first transaction.

That is already possible currently. EXPERIMENTAL_tx_status endpoint allows one to query execution outcomes and will return all the receipts the transaction generated.

[frol]

@khorolets we need a new EXPERIMENTAL_receipt method exposing Receipt info by a given Receipt ID (and chances are that we need to require Receiver Account ID due to sharding)

[khorolets]

I forgot to refer to this issue in #3883 I guess we can close the issue.