feat(rust-sdk): Simulate WaitForLocalExecution #18996
Conversation
## Description
If transaction execution requires waiting for local execution, then
simulate it by polling, to account for the fact that fullnodes will soon
start to ignore this parameter.
## Test plan
Run the programmable transaction SDK example:
```
sui-sdk$ cargo run --example programmable_transactions_api
```
Run the tic-tac-toe E2E example:
```
examples/tic-tac-toe/cli$ env $(cat testnet.env) \
cargo run -- new $(sui client active-address)
| |
---+---+---
| |
---+---+---
| |
-> X: <ADDRESS>
O: <ADDRESS>
GAME: <GAME>
examples/tic-tac-toe/cli$ env $(cat testnet.env) \
cargo run -- move -r 0 -c 0 $GAME
...
```
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
| @@ -180,6 +180,10 @@ impl SuiTransactionBlockResponseOptions { | |||
| } | |||
| } | |||
|
|
|||
| #[deprecated( | |||
There was a problem hiding this comment.
There is more we could do with the flags here (the criteria for requiring effects etc seems too generous), but I am resisting here seeing as we will be moving to a new SDK soon.
There was a problem hiding this comment.
Does default_execution_request_type need to be updated?
There was a problem hiding this comment.
I considered it but decided not to because I'm afraid it would open a can of worms that we would then need to deal with in the near term, even though the underlying issues would disappear with the GraphQL Rust SDK, namely:
- Why do we set
WaitForLocalExecutionon the basis ofrequire_effectsinstead of ...require_local_execution? - Why do we need to do anything special to get the raw effects?
It seems at some point these two things got conflated, and now it's easier to keep them coupled until we introduce GraphQL Rust SDK (or we get rid of WaitForLocalExecution as a flag on the client), because otherwise we might break the experience for people who are implicitly relying on read-write consistency they got from requesting just effects.
| if let Ok(poll_response) = self | ||
| .api | ||
| .http | ||
| .get_transaction_block(*tx.digest(), Some(options.clone())) |
There was a problem hiding this comment.
So I clearly have some gaps in my Transaction related functionality understanding, but once a transaction it's built, a digest is generated. That's why we can do polling, because we already know the digest. So the digest cannot change once the tx is built, correct? I thought digest is dependent on other factors (e.g., time when tx gets accepted)
There was a problem hiding this comment.
There are multiple kinds of digest -- the transaction digest, which we are using here, is derived from the transaction input so that is not going to change. There is also an effects digest, which is a hash of the transaction effects, so we will not know that until we get the full effects.
In the end, I tested this by modifying the fullnode implementation of |
## Description
If transaction execution requires waiting for local execution, then
simulate it by polling, to account for the fact that fullnodes will soon
start to ignore this parameter.
## Test plan
Run the programmable transaction SDK example:
```
sui-sdk$ cargo run --example programmable_transactions_api
```
Run the tic-tac-toe E2E example:
```
examples/tic-tac-toe/cli$ env $(cat testnet.env) \
cargo run -- new $(sui client active-address)
| |
---+---+---
| |
---+---+---
| |
-> X: <ADDRESS>
O: <ADDRESS>
GAME: <GAME>
examples/tic-tac-toe/cli$ env $(cat testnet.env) \
cargo run -- move -r 0 -c 0 $GAME
...
```
---
## Release notes
Check each box that your changes affect. If none of the boxes relate to
your changes, release notes aren't required.
For each box you select, include information after the relevant heading
that describes the impact of your changes that a user might notice and
any actions they must take to implement updates.
- [ ] Protocol:
- [ ] Nodes (Validators and Full nodes):
- [ ] Indexer:
- [ ] JSON-RPC:
- [ ] GraphQL:
- [ ] CLI:
- [X] Rust SDK: Adds support for simulating `WaitForLocalExecution` in
the client, using polling, as the flag will be ignored by fullnodes
shortly.
- [ ] REST API:
## Description
If transaction execution requires waiting for local execution, then
simulate it by polling, to account for the fact that fullnodes will soon
start to ignore this parameter.
## Test plan
Run the programmable transaction SDK example:
```
sui-sdk$ cargo run --example programmable_transactions_api
```
Run the tic-tac-toe E2E example:
```
examples/tic-tac-toe/cli$ env $(cat testnet.env) \
cargo run -- new $(sui client active-address)
| |
---+---+---
| |
---+---+---
| |
-> X: <ADDRESS>
O: <ADDRESS>
GAME: <GAME>
examples/tic-tac-toe/cli$ env $(cat testnet.env) \
cargo run -- move -r 0 -c 0 $GAME
...
```
---
## Release notes
Check each box that your changes affect. If none of the boxes relate to
your changes, release notes aren't required.
For each box you select, include information after the relevant heading
that describes the impact of your changes that a user might notice and
any actions they must take to implement updates.
- [ ] Protocol:
- [ ] Nodes (Validators and Full nodes):
- [ ] Indexer:
- [ ] JSON-RPC:
- [ ] GraphQL:
- [ ] CLI:
- [X] Rust SDK: Adds support for simulating `WaitForLocalExecution` in
the client, using polling, as the flag will be ignored by fullnodes
shortly.
- [ ] REST API:
Description
If transaction execution requires waiting for local execution, then simulate it by polling, to account for the fact that fullnodes will soon start to ignore this parameter.
Test plan
Run the programmable transaction SDK example:
Run the tic-tac-toe E2E example:
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.
WaitForLocalExecutionin the client, using polling, as the flag will be ignored by fullnodes shortly.