From 12ea49f0eb0fc97298d03c6c0aeb40e3ad36397f Mon Sep 17 00:00:00 2001 From: Olga Telezhnaya Date: Tue, 19 Sep 2023 19:43:01 +0100 Subject: [PATCH] Update transactions.md Change tx status method doc https://docs.near.org/api/rpc/transactions#transaction-status In reality, we wait until the block of the last corresponding receipt_id is final, and only then return the result. So the user does not need to check anything. --- docs/5.api/rpc/transactions.md | 30 ------------------------------ 1 file changed, 30 deletions(-) diff --git a/docs/5.api/rpc/transactions.md b/docs/5.api/rpc/transactions.md index 04039d17c70..b2187b044c4 100644 --- a/docs/5.api/rpc/transactions.md +++ b/docs/5.api/rpc/transactions.md @@ -470,36 +470,6 @@ http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=tx \

-
-heads up

- -In the case of function call transactions, this query will not wait for **all** receipts generated by this transaction to finish before returning a result. Rather, it will only wait for its return value to finish before returning; _which could be a promise_. - -Let's say a transaction only contains a "function call" action that calls a `transfer()` method like the one below _(written in [Rust](https://www.rust-lang.org/))_. It will only wait for the "function call" receipt, not necessarily the receipt from the actual transfer of funds to finish before returning a result. - -```rust -pub fn transfer(receiver_id: String) { - Promise::new(receiver_id).transfer(10); -} -``` - -However, if we slightly modify the function to have the promise as a return value, then the `tx` status query will wait for this promise to finish _before_ returning results. - -```rust -pub fn transfer_promise(receiver_id: String) -> Promise { - Promise::new(receiver_id).transfer(10) -} -``` - -Despite such design, the `tx` endpoint can be used to check whether all receipts have finished. - -Instead of looking at the main result `status`, we can check all of the receipts -returned `status` and see if any are `Unknown`. If none of the receipts statuses are unknown, we can be certain that all receipts generated have finished. - -In addition, `tx` endpoint does not provide finality guarantees. To make sure that the entire execution is final, it suffices to ensure every `block_hash` in every outcome is `final`. - -
- #### What could go wrong? {#what-could-go-wrong-2} When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow [verror](https://github.com/joyent/node-verror) convention for structuring the error response: