-
Notifications
You must be signed in to change notification settings - Fork 153
How should the dropped transactions be handled? #391
-
As far as I can see, the maxRetries parameter is not implemented to the sendTransaction method. It's like it was done intentionally.
Do you have any suggestions to implement this retry logic using Solnet safely?
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment 1 reply
-
A common pattern for manually retrying transactions involves temporarily storing the lastValidBlockHeight that comes from getLatestBlockhash. Once stashed, an application can then poll the cluster’s blockheight and manually retry the transaction at an appropriate interval.
This seems fairly straightforward, when you call GetLatestBlockhash you store the LastValidBlockHeight, then you enter a loop in which you retry to submit the transaction while pollling for the latest block height to compare with the LastValidBlockHeight.
Something like the following (oversimplified):
var blockheight = rpc.GetBlockHeight(Commitment.Confirmed);
while (blockheight < lastValidBlockHeight) {
rpc.SendTransaction(txBytes, skipPreflight: true, commitment: Commitment.Confirmed);
await Task.Delay(500).Wait();
blockheight = rpc.GetBlockHeight(Commitment.Confirmed);
}
Beta Was this translation helpful? Give feedback.
All reactions
-
Thank you for your support. Yep it is clear :) but I mean how can I override the default maxRetires parameter when using custom retry algorithm?
The sentence you quoted continues as follows:
In times of network congestion, it’s advantageous to set maxRetries to 0 and manually rebroadcast via a custom algorithm.
Beta Was this translation helpful? Give feedback.