Remove support for full configuration as RC record#11275
Remove support for full configuration as RC record#11275
Conversation
In early days we started to have one big configuration per service with all probe definitions. we migrated for one probe per RC record since then. We do not have to support the big configuration record as this is no longer distributed by RemoteConfig. Remove also appliedConfiguration as this map is in practice useless
|
Hi! 👋 Thanks for your pull request! 🎉 To help us review it, please make sure to:
If you need help, please check our contributing guidelines. |
jpbempel
added
comp: debugger
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 298086ae69
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // only visible for tests | ||
| Map<String, ProbeDefinition> getAppliedDefinitions() { | ||
| return appliedDefinitions; | ||
| return currentConfiguration.getDefinitions().stream() |
There was a problem hiding this comment.
getAppliedDefinitions() now dereferences currentConfiguration unconditionally, but currentConfiguration is only assigned after the first successful accept(...). DebuggerAgent.addReportToFlare() calls this method whenever the updater exists, so generating a flare before any remote config commit will throw a NullPointerException and fail diagnostics collection; the previous implementation returned an empty map in this state.
Useful? React with 👍 / 👎.
| Collection<ProbeDefinition> build() { | ||
| return definitions; | ||
| } | ||
| configurationAcceptor.accept(REMOTE_CONFIG, probeByConfigId.values()); |
There was a problem hiding this comment.
commit() forwards probeByConfigId.values() directly, which is a live view backed by the mutable HashMap. ConfigurationUpdater.accept() stores that collection in definitionSources, so subsequent accept/remove mutations in this listener can leak into later configuration merges before a remote-config commit boundary (e.g., when CODE_ORIGIN or EXCEPTION sources call accept concurrently), causing probes to be applied/removed outside the intended transaction semantics.
Useful? React with 👍 / 👎.
Debugger benchmarksParameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 9 metrics, 6 unstable metrics. See unchanged results
Request duration reports for reportsgantt
title reports - request duration [CI 0.99] : candidate=None, baseline=None
dateFormat X
axisFormat %s
section baseline
noprobe (335.874 µs) : 306, 366
. : milestone, 336,
basic (299.357 µs) : 292, 306
. : milestone, 299,
loop (8.993 ms) : 8988, 8998
. : milestone, 8993,
section candidate
noprobe (347.044 µs) : 296, 398
. : milestone, 347,
basic (298.379 µs) : 292, 305
. : milestone, 298,
loop (8.986 ms) : 8980, 8992
. : milestone, 8986,
|
1 participant
What Does This Do
In early days we started to have one big configuration per service with all probe definitions. we migrated for one probe per RC record since then. We do not have to support the big configuration record as this is no longer distributed by RemoteConfig.
Remove also appliedConfiguration as this map is in practice useless
Motivation
Additional Notes
Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: [DEBUG-5515, DEBUG-5511]
Note: Once your PR is ready to merge, add it to the merge queue by commenting
/merge./merge -ccancels the queue request./merge -f --reason "reason"skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.