-
Notifications
You must be signed in to change notification settings - Fork 4.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
v1.16: unpin tokio for solana client crate #32943
Conversation
@mvines please review this PR. |
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, this seems good to me. let's see how CI likes it
Looks like we have an audit issue on v1.16 currently. It should be fixed by #32948, so once that PR lands please rebase this PR to pick up the audit fix. |
Codecov Report
@@ Coverage Diff @@
## v1.16 #32943 +/- ##
========================================
Coverage ? 81.9%
========================================
Files ? 762
Lines ? 208055
Branches ? 0
========================================
Hits ? 170576
Misses ? 37479
Partials ? 0 |
@t-nelson - can you please take a look at this as well? I think it's safe enough. The PR title/description is not helpful unfortunately. tldr is that they need the token-dependency of the v1.16 version of the solana-client crate to be just "1", like it was for v1.14. The explicit mention of tokio v1.14.1 (in the workspace Cargo.toml) causes v1.14.1 to be thrust upon users of the v1.16 solana-client crate as published to crates.io |
where was the motivation expressed? all i see is "a year old" which... sounds like a preference. i'm pretty dubious of the major-only specifier in general. i don't think we want to allow downgrades to below 1.14.1, but i don't recall why we added the vendoring is always an option |
@t-nelson sorry for the lack of motivation in PR. The reason why v1.16 is locked on the tokio v1.14.1 is described in this issue #24644. This PR resolves the issues for downstream users importing the solana client crate. Please, check that the PR is safe enough. |
seems like bumping to "1.29.1" (as per #32430) would be safer that "1" given that there were issues somewhere between "1.14.1" and "1.29.1" that we don't want devs to stumble in to again. which would be possible with "1" |
Backporting #32430 is way to risky at the moment no? "1" is exactly what the v1.14 version of the solana-client crate requires, so this is actually reverting back to the previous setup that the devs were happy about |
"1" allows any version with it's still not clear to me why 1.14.1 is insufficient. without knowing that, i can't really characterize risk. downstream vendoring is sounding more and more like the right solution |
Cargo.lock prevents this from happening for our tree. For the crate users, "1" provides the same experience they already have when using the v1.14 version of
1.14.1 is fine for the v1.16 validator client, we're not changing that here at all. Again the Cargo.lock file saves us. So there's no risk for us, the only risk is for crates.io consumers but not really because they already deal with this same behaviour ("1") in v1.14 |
@t-nelson I agree with dropping the tilde only for solana-client, since "1.14.4" allows any update of the form "1.x.x". |
the risk to us is breaking
i realize now that i may not have been clear that i was proposing bumping the that's the risk i'm considering. i still have no idea what the reward is. if i proposed backporting a dependency version bump to so, ignoring the "age" of 1.14.1, what is the motivation for this dependency bump? |
@t-nelson Tokio is used in an Axum web app that also uses Solana client v1.14 inside it. We use the latest possible versions for our dependencies. Upgrading Solana to v1.16 forces us to downgrade tokio to For me as a developer using a dependency, it is unexpected to be forced to downgrade some of my dependencies when upgrading another dependency. We will probably use our Solana fork for unpinning Tokio version on v1.16. |
got it. so taking
understood, but we can't force preferences like this on the entire developer ecosystem without evidence of broad advantage
vendoring is always an option! once we clear 1.16, these long latent dependencies and msrv should be in our past. we're well aware of the pain that they cause. we feel it too 🙂 |
@andreisilviudragnea is your fork available for others to use? We have this exact same issue. |
Hi @fabioberger, Please show your support for #32878 and comment on the issue with the details of your problem. I still believe this is a problem that should be fixed by Solana team and not by the users of the library. We use a backport of #32430 on branch v1.16 https://github.com/neonlabsorg/solana/tree/backport-32430, which will be rebased constantly over the latest changes from v1.16 branch. |
In the interest of thoroughness, noting that we lost the more permissive tokio definition in |
The better decision is suggested in #33058 |
Problem
Tokio version specifier "~1.14.1" only allows patch updates and v1.14.1 is more than a year old.
Summary of Changes
Change to
tokio = "1"
in theclient/
crate.Fixes #32878