-
Notifications
You must be signed in to change notification settings - Fork 501
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
txnbuild: Add helper to calculate claimable balance IDs without submitting transactions. #3122
Conversation
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.
Yes! Thanks for doing this. Couple suggestions below.
This is a cleaner design than returning a list of IDs, because it actually enforces a correlation between the returned ID and a specific operation. Otherwise, it's strange to have the returned array be different that the list of operations in the transaction.
6523a47
to
ede3b89
Compare
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.
Thanks for doing this! I left a couple of nitpicks. This PR looks good to me, but I'd defer the approval to @leighmcculloch to make sure it looks good to him too before you merge the PR.
Docstrings and return values are cleaned up Co-authored-by: Howard Tinghao Chen <[email protected]> Co-authored-by: Leigh McCulloch <[email protected]>
PR Checklist
PR Structure
otherwise).
services/friendbot
, orall
ordoc
if the changes are broad or impact manypackages.
Thoroughness
.md
files, etc... affected by this change). Take a look in the
docs
folder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
Balance IDs are a crucial piece of information when dealing with claimable balances. They are highly predictable by design, and so SDK users shouldn't need to submit the transaction to determine the ID.
This PR introduces a helper within the txnbuild package:
It returns a claimable balance ID for the particular operation within the transaction, assuming it is of the type
CREATE_CLAIMABLE_BALANCE
.It also introduces an integration test to confirm this behavior. Since it's appended to an existing test, this only adds a few extra seconds of running time. I believe this also only can be integration tested since we need Core to actually run the calculation as well, but I'd love to be wrong.
Why
Closes #3116.
Known limitations
Obviously, this only applies to the Go SDK.
(added @jonjove to review to sanity-check the balance ID calculation and @leighmcculloch purely for visibility on the txnbuild changelog)