Refactor remote config for ASM to fix missing config#8630
Conversation
4ab4f30 to
9964a31
Compare
9964a31 to
5409973
Compare
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8630) and master. ✅ No regressions detected - check the details below Full Metrics ComparisonFakeDbCommand
HttpMessageHandler
Comparison explanationExecution-time benchmarks measure the whole time it takes to execute a program, and are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are highlighted in **red**. The following thresholds were used for comparing the execution times:
Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). Duration chartsFakeDbCommand (.NET Framework 4.8)gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8630) - mean (73ms) : 70, 75
master - mean (73ms) : 70, 75
section Bailout
This PR (8630) - mean (76ms) : 75, 78
master - mean (79ms) : 75, 83
section CallTarget+Inlining+NGEN
This PR (8630) - mean (1,110ms) : 1055, 1164
master - mean (1,104ms) : 1056, 1153
FakeDbCommand (.NET Core 3.1)gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8630) - mean (114ms) : 110, 117
master - mean (113ms) : 109, 117
section Bailout
This PR (8630) - mean (117ms) : 111, 123
master - mean (118ms) : 113, 124
section CallTarget+Inlining+NGEN
This PR (8630) - mean (790ms) : 760, 819
master - mean (787ms) : 759, 814
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8630) - mean (102ms) : 97, 106
master - mean (102ms) : 98, 106
section Bailout
This PR (8630) - mean (106ms) : 101, 110
master - mean (106ms) : 100, 111
section CallTarget+Inlining+NGEN
This PR (8630) - mean (945ms) : 910, 980
master - mean (946ms) : 907, 986
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8630) - mean (100ms) : 96, 104
master - mean (99ms) : 95, 103
section Bailout
This PR (8630) - mean (100ms) : 98, 103
master - mean (103ms) : 98, 108
section CallTarget+Inlining+NGEN
This PR (8630) - mean (828ms) : 793, 863
master - mean (822ms) : 788, 856
HttpMessageHandler (.NET Framework 4.8)gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8630) - mean (200ms) : 194, 206
master - mean (202ms) : 194, 210
section Bailout
This PR (8630) - mean (204ms) : 198, 209
master - mean (206ms) : 198, 213
section CallTarget+Inlining+NGEN
This PR (8630) - mean (1,207ms) : 1157, 1256
master - mean (1,205ms) : 1159, 1251
HttpMessageHandler (.NET Core 3.1)gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8630) - mean (289ms) : 282, 296
master - mean (288ms) : 281, 295
section Bailout
This PR (8630) - mean (288ms) : 283, 294
master - mean (290ms) : 283, 296
section CallTarget+Inlining+NGEN
This PR (8630) - mean (967ms) : 946, 989
master - mean (967ms) : 941, 992
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8630) - mean (281ms) : 274, 288
master - mean (281ms) : 275, 287
section Bailout
This PR (8630) - mean (281ms) : 276, 286
master - mean (280ms) : 275, 285
section CallTarget+Inlining+NGEN
This PR (8630) - mean (1,158ms) : 1114, 1202
master - mean (1,163ms) : 1117, 1208
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8630) - mean (279ms) : 271, 288
master - mean (281ms) : 274, 289
section Bailout
This PR (8630) - mean (278ms) : 272, 285
master - mean (282ms) : 275, 288
section CallTarget+Inlining+NGEN
This PR (8630) - mean (1,039ms) : 995, 1084
master - mean (1,041ms) : 997, 1085
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BenchmarksBenchmark execution time: 2026-05-14 13:22:31 Comparing candidate commit 5409973 in PR branch Some scenarios are present only in baseline or only in candidate runs. If you didn't create or remove some scenarios in your branch, this maybe a sign of crashed benchmarks 💥💥💥 Scenarios present only in baseline:
Found 0 performance improvements and 4 performance regressions! Performance is the same for 47 metrics, 21 unstable metrics, 85 known flaky benchmarks, 41 flaky benchmarks without significant changes.
|
Summary of changes
Reason for change
ReceivedNewConfig()is responsible for "remembering" ASM config it receives when ASM is disabled, so that they can be applied if/when ASM is enabled via remote config.ReceivedNewConfig()was explictily clearing pending updates and removes as it assumed that when we receive the "full" config each time, but that's not the case. Consequently, it means that you'd "lose" any previous config when a new incremental update came in.The "simple" fix is to stop clearing those collections. But that gives other problems:
Consequently, a larger refactor was required.
Implementation details
_fileUpdatesand_fileRemovesinto a single dictionary_pendingByProduct, to make tracking update then delete then update changes more easily without needing to search lists.ReceivedNewConfig(). This was the original bug.Pathinstead of lists (required, because we're not clearing each call, so duplicates are possible/likely, and could grow unbounded)GetWafConfigurations->BuildWafUpdatePayloadbecause this mutates the_pendingByProductcollectionFor the record, this is like the 5th iteration of this code, it's really not nice to work with 😅
Test coverage
Added some regression tests, because there were none at all before. Can't guarantee all the invariants are correct though unfortunately given the lack of existing tests 😟