Closed Rahat-ch closed 2 months ago
It's the same throughput issue. Our testnet node (which is behind main) is pretty much consistently operating past the limit of what the node can handle most of the time it seems.
Again this most likely has to do with transaction by hash requests being based on polling and using the same channel as submissions. There's a bit of a viscous cycle here. First the node backs up mainly due to DA throughput, this slows the transaction confirmation speed which results in more transaction by hash requests per transaction because they are polled. This, then becomes bad enough to backup the transaction channel to the point where the Tokio runtime has to actually drop requests.
However, from our experiment, it's only the smart contract with resource account that is effected. The success rate is literally 0%. For smart contract without resource account, the success rate is much better and not effected.
Do you have any more insights about this specific performance difference between smart contract with & without resource account?
Is this still an issue after the recent upgrades?
@Rahat-ch
looks to be resolved closing
Describe the bug Modules that are utilizing Resource accounts are unable to perform transactions completely after about 6 hours of transactions according to data collected by Rize. The error that occurs is the following mempool issue:
Code available here: https://explorer.movementlabs.xyz/account/0xd697cbe1d0ab95d9c79f847ee7a075db6e5d99196328785ff354fcbda7e28652/modules/code/momo?network=testnet
Rize redeployed their modules without resource accounts and see that when they do not use resource accounts their smart contracts are running well.
To Reproduce Curl command to reproduce:
Expected behavior
Transaction with resource accounts should run normally