-
Notifications
You must be signed in to change notification settings - Fork 39
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.
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
feat: refactor smart transaction sender & confirmation #114
Conversation
…onfirmTransaction params
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a few comments/questions that need to be resolved, but other than that, very based! Thank you for your contribution!
Awesome. I'm currently away on a trip, so I will fix everything when I get back. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extremely based! Just one nit, but LGTM 🔥
Also, for future PRs, can you please make a separate branch instead of pushing from |
I'm going to go ahead and merge — I'll take out the unused import myself. Thank you for your contribution! |
Sure, will do that next time! Do you think we can get this released soon? |
Yes, we'll cut a new release soon to include all of the recent PRs. I have a few more things I need to implement and get reviewed, but I'll make sure it happens as fast as possible 🫡 |
This PR is the continuation of #97.
The new confirmation strategy uses the
confirmTransaction
, with the possibility of adding an offset to thelastValidBlockHeight
option. The reason for that is to address scenarios where the transaction is included after thelastValidBlockHeight
due to network latency or due to the leader not forwarding the transaction for an unknown reason.Trade-off: better reliability at the cost of possible longer confirmation times.
Addresses #112