Skip to content

Conversation

GodTamIt
Copy link

@GodTamIt GodTamIt commented Sep 5, 2025

Motivation

Dependents of svix in Rust may use newer versions of hyper and rustls (a dependency in the chain). This helps the package keep up with the latest version so that older versions of these dependent libraries don't have to be compiled.

Solution

Bumps hyper dependencies to the latest versions.

@GodTamIt GodTamIt requested a review from a team as a code owner September 5, 2025 19:54
svix-jplatte
svix-jplatte previously approved these changes Sep 11, 2025
Copy link
Member

@svix-jplatte svix-jplatte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@svix-jplatte
Copy link
Member

FYI, only the hyper-rustls upgrade is meaningful. The hyper upgrade is semver-compatible, so any project that would be upgraded to it by upgrading the svix library may just as well run cargo update -p hyper (or plain cargo update) already to get the latest version.

svix-jplatte
svix-jplatte previously approved these changes Sep 12, 2025
@svix-jplatte
Copy link
Member

svix-jplatte commented Sep 12, 2025

Could you please do a quick cargo check in both svix-cli/ and bridge/ to update the lockfiles, and commit the updated lockfiles? Both of these depend on the Rust SDK as a path dependency, so their lockfiles change from this.

@svix-jplatte
Copy link
Member

CI failure are likely unrelated.

  • security_audit fail is due to a crate we use in bridge now being marked unmaintained (I opened bridge: Upgrade deno #2062 for this)
  • not sure about the test failure, probably flakiness

@GodTamIt
Copy link
Author

Hang on, the tests are affected by the change. Uploading a fix in a bit

@svix-jplatte
Copy link
Member

Oh, yeah. I didn't look in detail, I just saw one test that used to be very flaky mentioned, and assumed it was the same thing again.

@svix-jplatte
Copy link
Member

Sorry, I don't think changing bridge to make the Svix SDK work is a reasonable solution. The SDK should definitely not require any prior setup to use like this, as it would break many existing users.

@GodTamIt
Copy link
Author

@svix-jplatte An option could be that the library attempts to install or use a default if one isn't installed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants