Skip to content
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

Switch to upstream launchdarkly sdk #31392

Closed
wants to merge 1 commit into from

Conversation

antiguru
Copy link
Member

@antiguru antiguru commented Feb 7, 2025

Switch to the upstream launchdarkly-server-sdk crate instead of our own
fork. This comes at the expense of losing some metrics that we added to
our crate but never attempted to upstream. It is not easy to replicate
the metrics without creating our own wrapper of the http library (or
continue to maintain our own fork). I'd rather lose the metrics over
continuing to maintain our own fork because the maintenance will cost time.

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

@antiguru antiguru requested a review from a team as a code owner February 7, 2025 10:36
@antiguru antiguru requested review from ParkMyCar and def- February 7, 2025 10:36
Copy link
Contributor

@pH14 pH14 left a comment

Choose a reason for hiding this comment

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

Would we lose the connection timeouts in MaterializeInc/rust-server-sdk@59b5740? I'd be OK losing metrics, but having timeouts on all external calls has proven to be very important

Switch to the upstream launchdarkly-server-sdk crate instead of our own
fork. This comes at the expense of losing some metrics that we added to
our crate but never attempted to upstream. It is not easy to replicate
the metrics without creating our own wrapper of the http library (or
continue to maintain our own fork). I'd rather lose the metrics over
continuing to maintain our own fork because the maintenance will cost time.

Signed-off-by: Moritz Hoffmann <[email protected]>

# Conflicts:
#	Cargo.lock
#	src/balancerd/Cargo.toml
@antiguru
Copy link
Member Author

Yup, there's no API for setting the timeouts.

@antiguru
Copy link
Member Author

Closing this PR because I don't want to spend more time on it.

@antiguru antiguru closed this Feb 10, 2025
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.

4 participants