[Feature Flags] Bind discovery results to the Agent endpoint - #9352
leoromanovsky wants to merge 1 commit into
Conversation
Invalidate cached capabilities on endpoint replacement and reject stale responses before publishing configuration or hashes. Report EVP identity-header forwarding support without changing product routing. Environment: Datadog workspace
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b16a7dcc32
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| _apiRequestFactory = new(factory, exporterSettings); | ||
| // A different Agent must be polled even if it returns the same body/hash. Never | ||
| // replay the previous Agent's cached capabilities to a new subscriber. | ||
| _configuration = null; | ||
| _configurationHash = null; |
There was a problem hiding this comment.
Revoke capabilities held by existing subscribers
When the Agent endpoint changes after discovery has completed, clearing _configuration only prevents future subscribers from receiving the old snapshot; already-registered subscribers are not notified and continue using capabilities learned from the previous Agent. For example, RemoteConfigurationManager.SetRcmEnabled retains its prior value indefinitely if discovery against the replacement Agent fails, so clearing the cache does not actually enforce the endpoint boundary for normal production subscribers. Publish an invalidated snapshot or otherwise revoke the old capabilities when replacing the factory.
Useful? React with 👍 / 👎.
| _apiRequestFactory = new(factory, exporterSettings); | ||
| // A different Agent must be polled even if it returns the same body/hash. Never | ||
| // replay the previous Agent's cached capabilities to a new subscriber. | ||
| _configuration = null; | ||
| _configurationHash = null; |
There was a problem hiding this comment.
Wake the discovery loop when replacing the endpoint
If the endpoint changes while the discovery loop is in its normal 30-second delay, resetting these fields does not interrupt that delay, so the replacement Agent is not queried until the interval expires. The same delay occurs when an old in-flight response is discarded: RunOneIterationAsync still returns success and the loop sleeps for the full recheck interval; the new test avoids this only by manually starting a concurrent second iteration, which the production loop never does. Signal the loop on replacement or make a discarded response trigger an immediate retry.
Useful? React with 👍 / 👎.
BenchmarksBenchmark execution time: 2026-10-01 23:17:41 Comparing candidate commit b16a7dc in PR branch Found 0 performance improvements and 10 performance regressions! Performance is the same for 62 metrics, 0 unstable metrics, 74 known flaky benchmarks, 52 flaky benchmarks without significant changes.
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (9352) and master. ✅ No regressions detected |
Motivation
Changing the Agent endpoint at runtime must not make the SDK trust capabilities learned from the previous Agent. Cached configuration and late responses currently cross that boundary, which can misroute telemetry or lose its producer identity.
flowchart LR A[Old Agent request] --> C[Cached capabilities] E[Endpoint changes] -. missing invalidation .-> C C --> B[Replacement Agent]Changes and Decisions
Bind each discovery result to the immutable exporter settings used for its request. Replacing the endpoint clears cached configuration and refresh hashes; late responses from the old endpoint cannot publish capabilities or hashes. An identical response from the replacement still notifies consumers.
Discovery also reports whether the relay forwards both EVP producer-identity headers. This exposes a capability; it does not change any product's route selection or enable direct intake.
This is the foundation of the delivery stack: discovery here, bounded exposure lifecycle in #9353, then Agentless fallback in #9235. Each PR contains one commit relative to its base.
flowchart LR E[Current exporter settings] --> R[Discovery request] R --> G{Still current?} G -->|Yes| C[Publish capabilities for this endpoint] G -->|No| D[Discard old response]