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.

Sign up for GitHub

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

Change tx status method doc #1499

Merged
merged 1 commit into from
Jan 8, 2024
Merged

Change tx status method doc #1499

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 0 additions & 30 deletions docs/5.api/rpc/transactions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -470,36 +470,6 @@ http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=tx \
</p>
</details>

<blockquote class="warning">
<strong>heads up</strong><br /><br />

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`.

</blockquote>

#### 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:
Expand Down
Loading