-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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: Add tokio support to anchor_client RequestBuilder
#3057
feat: Add tokio support to anchor_client RequestBuilder
#3057
Conversation
@cryptopapi997 is attempting to deploy a commit to the coral-xyz Team on Vercel. A member of the Team first needs to authorize it. |
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. I haven't tried it locally, but it looks great in terms of implementation other than a couple of small issues/questions I mentioned.
Fully backwards compatible.
It's mostly backwards compatible, but since RequestBuilder
is public, introducing a new generic can be a breaking change for people who implement their own trait for that type (low probability).
Adapted according to your review:
True, although even in this case the fix is relatively easy. It's just a matter of implementing it for
Lmk what you think @acheroncrypto |
All SemVer violations can potentially result in build errors for downstream projects, no matter how easy the fix is e.g. #3044. It's better to be safe in this case, and consider this a breaking change. |
You're right. In this case, replacing |
All done, take a look @acheroncrypto |
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, it looks great now! However, there is an unrelated problem: solana-labs/solana-program-library#6897 is still not resolved, so we might have to make another patch release soon depending on the resolution of that issue. In that case, it would be easier to merge this PR afterwards since this is a breaking change (and I don't want to deal with multiple branches).
We shouldn't need a patch release if they just do the solution in #3044 (comment) though.
Since #3044 is now resolved, could you make the CI rerun so we can get this merged? @acheroncrypto |
Also this PR needs the "breaking" tag |
Co-authored-by: acheron <[email protected]>
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.
Looks great, thanks!
Suffering on this, but I cannot use the latest anchor due to Solana version constraints. Not sure what are my options 🥴 |
You basically have two options in that case:
Downside is you then have to maintain your own fork, so whichever of these two options is the least effort |
Picking up on #3006 since we need this for Arcium.
Adds
request_threadsafe
which creates a threadsafe request for usage in tokio. Fully backwards compatible.Idk if #3053 breaks this, so would be good to get this PR merged before that one. Lmk what you think @acheroncrypto