-
Notifications
You must be signed in to change notification settings - Fork 15
chore(remote-config): make live debugger optional feature #1246
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
Conversation
BenchmarksComparisonBenchmark execution time: 2025-09-26 07:47:42 Comparing candidate commit f4f7fe7 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 53 metrics, 2 unstable metrics. CandidateCandidate benchmark detailsGroup 1
Group 2
Group 3
Group 4
Group 5
Group 6
Group 7
Group 8
Group 9
Group 10
Group 11
Group 12
Group 13
Group 14
Group 15
BaselineOmitted due to size. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1246 +/- ##
==========================================
+ Coverage 71.57% 71.68% +0.11%
==========================================
Files 355 355
Lines 56309 56312 +3
==========================================
+ Hits 40302 40368 +66
+ Misses 16007 15944 -63
🚀 New features to boost your workflow:
|
| endpoint: self.endpoint.clone(), | ||
| #[cfg(not(feature = "live-debugger"))] | ||
| products: vec![RemoteConfigProduct::ApmTracing], | ||
| #[cfg(feature = "live-debugger")] |
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.
when another product is added as optional this will be require an even more complex setup.
I think the code must be changed to just add to the vector as needed instead of just trying to jam it in as a one-liner
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.
Indeed, but this is just a test server and I wanted to make sure that I didn't break anything that relied on the existing code.
The RC create really needs to be refactored to better allow for not knowing about all the types and deserialize them itself. That is a bigger task for Q4.
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.
It conveniently allows storing the deserialized data directly on the storage. I'd like to trade as little convenience as possible.
Is there a fundamental benefit of not having to know about all the types? As long as we can simply enable and disable via feature flags, why not actually?
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.
I agree that storing the deserialized data directly is very convenient. I don't advocate for throwing that away, but I think that we should explore if there is another way to split things.
Long term, I don't think that feature flags will be maintainable as we add more products, and there is also the circular nature of the RC data types that I think should be defined with the code that uses them, but that code also depends on RC to get the data.
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
What does this PR do?
Move live debugger remote configuration functionality behind a feature flag.
Motivation
Avoid pulling in unnecessary dependencies for users that don't need live debugging.