Add example using legacy rpc #1259
Conversation
|
Light client test failed... I don't think that is related to this patch is it? |
No, the examples are not executed in the CI only type-checked. |
subxt/examples/legacy_rpc.rs
Outdated
| ); | ||
| // Sleep less than block time, but long enough to ensure | ||
| // not all transactions end up in the same block. | ||
| tokio::time::sleep(tokio::time::Duration::from_secs(4)).await; |
There was a problem hiding this comment.
Would it be possible to deduce this without relying on sleeps? One approach might be subscribing to finalized/best headers 🤔
There was a problem hiding this comment.
Would it be possible to deduce this without relying on sleeps? One approach might be subscribing to finalized/best header
No what I'm trying to do here is not to wait for blocks to be finalized. I submit the transactions with a delay so the nonce would get out of sync if not adjusting for transactions in the pool.
| // RPC call System.account_next_index will adjust for transactions already in | ||
| // the pool | ||
| println!( | ||
| "AccountNonce: {:?} System.account_next_index: {:?}", |
There was a problem hiding this comment.
IIUC, without the 4 seconds sleep we'd eventually after running a few times have different values those 2 methods?
There was a problem hiding this comment.
@lexnv even wihtout the delay api.tx().account_nonce(&alice) will lag
| ); | ||
|
|
||
| for (dest, amount) in transactions { | ||
| let nonce = rpc.system_account_next_index(&alice).await?; |
There was a problem hiding this comment.
Given that dev::bob() makes multiple transactions here, did you encounter an edge case with the default API that motives the use of system_accountNextIndex?
Something of the following lines:
- create two
dev::bob()tx during the same finalized block - the nonce returned by subxt is identical between the two transactions
- one transaction is inserted into the pool, while the other is rejected with invalid nonce for the same target block?
There was a problem hiding this comment.
Given that
dev::bob()makes multiple transactions here, did you encounter an edge case with the default API that motives the use ofsystem_accountNextIndex?
Yes that is how this started in my primary project a few months back, when the client was disconnected, suddenly nonce could come out of sync. First I solved it with dead counting, which was better but still had issues when disconnected and extrinsics still pending in the transaction pool. I was about to start implementation of code compensating for pending transactions when I was made aware of the system_accountNextIndex rpc call
https://github.com/paritytech/polkadot-sdk/blob/8d2637905ba920dd1f0e8f1212ec98e45420f514/substrate/utils/frame/rpc/system/src/lib.rs#L44-L48
vs
https://github.com/paritytech/polkadot-sdk/blob/8d2637905ba920dd1f0e8f1212ec98e45420f514/substrate/frame/system/rpc/runtime-api/src/lib.rs#L28-L35
IIUC, without the 4 seconds sleep we'd eventually after running a few times have different values those 2 methods?
Even without the wait the two methods will show different values but as in this example below AccountNonce: 173 never advances beyond 173, as all transactions are submitted during the same block.
📛 System Name: "Nodle Parachain Collator"
🩺 Health: SystemHealth { peers: 4, is_syncing: false, should_have_peers: false }
🖫 Properties: {}
🔗 Chain: "Parachain Eden Development"
Submitting 0xa71835a1d8aa950205942f18916140327687e5fd1d4f1b935e494ce0eca46fb1 with Nonce:173
AccountNonce: 173 System.account_next_index: 174
Submitting 0x3e6d25bff8c8335bf2d11e976b38a5320cf65dcf71a119ea01f803fd92076ba2 with Nonce:174
AccountNonce: 173 System.account_next_index: 175
Submitting 0x965759df618a61ab8994d9b2e2e3a021b860a28d1bcafdeac7fdf67b84a05467 with Nonce:175
AccountNonce: 173 System.account_next_index: 176
Submitting 0xd20f7b8e04b58287b6739fdf8f4c081b1108b17b832d6d67cdeb2bf35699a76f with Nonce:176
AccountNonce: 173 System.account_next_index: 177
Submitting 0x2a07b1d076485b1e9d612d7b6f36d69be6d2d196f79d30bdaf5993dc71d2994b with Nonce:177
AccountNonce: 173 System.account_next_index: 178
Submitting 0x1cb56cd65db9b91321762e308caf2bf20972e6736985b9f0fab46b8110a88ac5 with Nonce:178
AccountNonce: 173 System.account_next_index: 179
Submitting 0xbf3ad84ed5aaec17fa488847b2b811bb47ee179c2447c626857c94b63eccb820 with Nonce:179
AccountNonce: 173 System.account_next_index: 180
Submitting 0xb273198a2156ca0236a6d16cc0a2f41ee159801e0aa3f72115024216f58eda15 with Nonce:180
AccountNonce: 173 System.account_next_index: 181
Submitting 0xe5adaf9ce38672d605dafb791d2e8aaaf7d2b5bef52819b127fc49da6f203e6f with Nonce:181
AccountNonce: 173 System.account_next_index: 182
Submitting 0x4f7b8af31358ed32f70b15528dab346d9737399fc54401c6fb1ef4f43f3b226d with Nonce:182
AccountNonce: 173 System.account_next_index: 183
Submitting 0xf8d1d73b4d364636c588e604e8e00c18cc45d0c20f56b290725f1e33cd480f3e with Nonce:183
AccountNonce: 173 System.account_next_index: 184
Submitting 0x7ef60b7ab507f4c3ddf3733336618db465cbd7ccc0e57507f22224a48678bc2f with Nonce:184
AccountNonce: 173 System.account_next_index: 185
Submitting 0xc1fbc77de293feb9d86c766f33040641362c1d018475e9e5f305842e66802bff with Nonce:185
AccountNonce: 173 System.account_next_index: 186
Submitting 0x7a04c164a444c2793ea3635120b17bd84b2c24ccbf2c6a5f280d93385ef28be2 with Nonce:186
AccountNonce: 173 System.account_next_index: 187
Submitting 0x4f0adfe8496f32ba1620d7b54b3bbb35dc18321bb5b35d61889ad43642df7106 with Nonce:187
AccountNonce: 173 System.account_next_index: 188
But with the wait, it runs slow enough for blocks to be finalized:
📛 System Name: "Nodle Parachain Collator"
🩺 Health: SystemHealth { peers: 4, is_syncing: false, should_have_peers: false }
🖫 Properties: {}
🔗 Chain: "Parachain Eden Development"
Submitting 0xffd60614dabf6fb7c29c6145440d98f84c90317d089b349730470e21767264a0 with Nonce:188
AccountNonce: 173 System.account_next_index: 189
Submitting 0x3683c43bb4994073671dce534aa00546091099a2ebd6a13c348cbd812a27deac with Nonce:189
AccountNonce: 173 System.account_next_index: 190
Submitting 0x0feafce6bbf129b233411fde524b72ff1b85206f7f0cf358cd7423889dc14086 with Nonce:190
AccountNonce: 173 System.account_next_index: 191
Submitting 0x6221a44c4b0015806ab4e928bf786cbc30bd6e2a2051fe9235452731e8202680 with Nonce:191
AccountNonce: 173 System.account_next_index: 192
Submitting 0x6da820053e71fd59fe89830e936ef3c74001038d9a70f9544d9e4737a4677b48 with Nonce:192
AccountNonce: 173 System.account_next_index: 193
Submitting 0x41a6e8ba6a078882ef4dc69c903259a66f6a90b488c952f3699fbf7aa3bc01f9 with Nonce:193
AccountNonce: 188 System.account_next_index: 194
Submitting 0xef951296a4be83409705e8b625c31edb300e007ecdad7af4e8c33c7a8ca7c2fc with Nonce:194
AccountNonce: 188 System.account_next_index: 195
Submitting 0x90722d382dfbc8561b27aa07ff2c49ccee072f9c101c5f9c9fe6c493190f5058 with Nonce:195
AccountNonce: 188 System.account_next_index: 196
Submitting 0x39169c33815ee98194f9cb83c1b307b23ad329e3a0b5827c626515aff5ca3c2c with Nonce:196
AccountNonce: 189 System.account_next_index: 197
Submitting 0xd7b8c7806ebfa7cd93ca32b8e357888a77a04209e02eab53fe0d73ab1650dc45 with Nonce:197
AccountNonce: 189 System.account_next_index: 198
Submitting 0xef2028aaec5e5946e7d00d6580205ddb33d9ff13bcef990f865e2ac70965f32c with Nonce:198
AccountNonce: 189 System.account_next_index: 199
Submitting 0x4be17205b33613b4b5207118180f94e609f24232ec08ccf84e79278c66e1b6fb with Nonce:199
AccountNonce: 192 System.account_next_index: 200
Submitting 0xd53242a972473775b95524a06e32aa06538a6118370f0e6eb2459aebed07c44e with Nonce:200
AccountNonce: 192 System.account_next_index: 201
Submitting 0x7da1a39f7f56ca51932d2286d50abfd103f29fb820c9694dd0bbb44cba972588 with Nonce:201
AccountNonce: 192 System.account_next_index: 202
Submitting 0xb1abcb2914a981f8e3af810cd343f491de8d29c9dc379c66bf1e3cf9b94a6570 with Nonce:202
AccountNonce: 195 System.account_next_index: 203
When all transactions are completed and finalized, the both methods will again show the same value. Should I add a few lines illustrating this?
There was a problem hiding this comment.
Feel free to make any changes to this as you like to make it fit in to this project better. I just wanted to give back some of the lessons I learnt while using subxt in my main project to the community and writing the example code I could not find when I needed it.
There was a problem hiding this comment.
22f563d could be rolled back if it does not fit.
There was a problem hiding this comment.
@lexnv did my explanation to you question make sense or should I try to be more clear what I'm trying to do?
What do we need to change to be able to conclude and merge an rpc-legacy example?
|
Thanks for your contribution @simonsso! I'm going to branch off this and tweak the example/fit it into our book properly! I def thing that showing people how to instantiate and use RPC methods in addition to the full Subxt client is valuable. I think I'll compact down the submitting-lots-of-transacitons bit though so that the focus is more on how to instantiate the client rather than the particular account_next_index use case, but lemme see! Edit: doing this in #1279 |
|
I do also wonder what the best approach to submitting multiple transactions is. I guess there are a few alternatives: First, if you have multiple TXs to submit from a user at once then you can either:
If you just have one TX to submit from a user, but may have more to submit soon (maybe there is a stream of txs coming in for instance):
Final thought: the new RPCs (https://github.com/paritytech/json-rpc-interface-spec/) don't have an equivalent to this account_next_index call really at the moment. I wonder whether they should. |
|
Superseded by #1279 |
Created an example using Legacy RPC and illustrate how the two nonce functions (
api.tx().account_nonce(),andrpc.system_account_next_index()) works.A few balance transfers are created, they are submitted in a pace to make it as difficult as possible to keep nonce updated.
The example also shows how to create mortal transactions and submit without waiting for the transactions to complete.
The code has been executed with