Implement rcte2 - Configuration apply status#3175
Conversation
141a21f to
ae1aed7
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
andrewlock
left a comment
There was a problem hiding this comment.
Mostly minor comments, but I'd prefer that we didn't use the file-based RCM for testing, and instead added the expected responses to the Mock Agent
| // can only move from unack to ack | ||
| if (applyDetails.ApplyState == ApplyStates.UNACKNOWLEDGED) | ||
| { | ||
| applyDetails.ApplyState = ApplyStates.ACKNOWLEDGED; | ||
| } |
There was a problem hiding this comment.
What if it was an error before? we leave it as errored, even though it's now acknowledged? That differs with the behaviour in RemoteConfigurationCache AFAICT?
There was a problem hiding this comment.
If an error occurred, I would rather know about the error than if it was acknowledged as well, though in an ideal world we'd know about both, but that's not possible with current interface to the backend.
There was a problem hiding this comment.
That's fair enough, my bigger question/concern was the disparity with RemoteConfigurationCache, and whether that's an issue
There was a problem hiding this comment.
This bit of code is all called if the remote config client detects a change in the message. I believe it actually plays nicely with resetting RemoteConfigurationCache , each time the messages change. On each remote config message change we:
- reset the cache so ApplyState passes to Unack
- attempt to apply all the new state to all listeners
- update ApplyState according to what happened in the listener
However, I do agree this creates a coupling between the cache and the way ApplyState is handled that is rather delicate, but not sure how this could be improved?
e7f037b to
7c1753d
Compare
This comment has been minimized.
This comment has been minimized.
Co-authored-by: Andrew Lock <[email protected]>
8bdccfd to
7133598
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| { | ||
| configurations ??= new List<byte[]>(); | ||
| configurations.Add(config.Contents); | ||
| filteredConfigs ??= new List<NamedRawFile>(); |
There was a problem hiding this comment.
Never seen this compact operator before. #TIL
| var request1 = await agent.WaitRcmRequestAndReturnLast(); | ||
| CheckAckState(request1, expectedState, null, "First RCM call"); | ||
| // even the request show the applied state seems extra time is needed before it's active | ||
| await Task.Delay(1500); |
There was a problem hiding this comment.
Could this be executed inside WaitRcmRequestAndReturnLast?
There was a problem hiding this comment.
It could but it's not needed in TestRemoteConfigError(), for example, because we don't do any further calls.
I'm quite surprised it's needed at all, since if the client state has come through I thought that meant the config had been applied, so further waiting shouldn't be necessary. It might be interesting to find out at some point why it is necessary.
dromanol
left a comment
There was a problem hiding this comment.
LGTM. Furthermore, I guess Rcm test flakyness will be gone with the introduced changes.
|
|
||
| private void AcceptConfiguration(ProductConfigChangedEventArgs args) | ||
| { | ||
| Log.Information("AcceptConfiguration: Starting ..."); |
There was a problem hiding this comment.
Do we want to keep this logging here? Seems a bit chatty (these would pop up in logs every 5 seconds I assume?)
There was a problem hiding this comment.
Or otherwise maybe just reduce log verbosity?
There was a problem hiding this comment.
Thanks, these were for my own debugging, I deleted most of them, seems these two slipped thought. Fixed in ae8a05e.
There was a problem hiding this comment.
Cool, thanks! Note that ae8a05e didn't include this deletion, maybe you haven't pushed the right commit in yet?
|
|
||
| private void CheckAckState(GetRcmRequest request, uint expectedState, string expectedError, string message) | ||
| { | ||
| var state = request?.Client?.State?.ConfigStates?.FirstOrDefault(x => x.Product == "FEATURES"); |
There was a problem hiding this comment.
| var state = request?.Client?.State?.ConfigStates?.FirstOrDefault(x => x.Product == "FEATURES"); | |
| var state = request?.Client?.State?.ConfigStates?.SingleOrDefault(x => x.Product == "FEATURES"); |
Benchmarks Report 🐌Benchmarks for #3175 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AppSecBodyBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ElasticsearchBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SpanBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️Raw results
|
Code Coverage Report 📊✔️ Merging #3175 into master will not change line coverage
View the full report for further details: Datadog.Trace Breakdown ✔️
The following classes have significant coverage changes.
The following classes were added in #3175:
View the full reports for further details: |
Summary of changes
A system that allows a remote config client to acknowledge each file provided by RC.
Reason for change
It will allows us to support customers using remote config more easily.
Implementation details
As remote config is event based, acknowledging a file relies on the subscriber of the products event to call a method on the event args class to acknowledge successful application of the config. If an error was thrown then the config will automatically be set into an error state. A subscribe can also explicitly set an error if they whish.
Test coverage
The feature is covered by an integration test, which includes a new mechanism for recovering the remote config request.