lizhimins commented on PR #4133: URL: https://github.com/apache/rocketmq-dashboard/pull/4133#issuecomment-5602182252
Closed as folded into #4119, merged into `rocketmq-studio` as f04dea2b. The production fix shipped exactly as you wrote it: the discovery-failure sample now carries empty labels instead of `proxyAddr=unknown`, so it lands in the whole-scope failure marker that #2957 established and `NativeAlertProcessor.containsWholeScopeFailure` skips reconciliation instead of resolving every firing proxy alert during an outage. Keeping the real `proxyAddr` on the three per-proxy failure paths was the right scoping — a single unreachable proxy should still reconcile normally. Your reasoning also matches `ApacheRocketMqClusterMetricsCollector`'s nameserver failure sample, so the two collectors are now consistent. One change was made during integration, to the tests rather than the fix. Your `ApacheRocketMqProxyMetricsCollectorTest` case is what pins this properly: it drives the real collector and asserts the emitted labels are empty, so reverting the fix turns it red. The companion case added to `NativeAlertProcessorTest` was dropped, because it constructed the empty-label `MetricSample` inline and therefore still passed with the collector fix reverted — it exercised the processor's pre-existing whole-scope handling, which `doesNotResolveMissingActiveStateWhenCollectionReportsWholeScopeUnavailableTest` already covers. Deleting it cost no coverage; keeping it would have implied the end-to-end path was pinned when it was not. `NativeAlertProcessorTest` runs 18 green and the collector test 3 green. For context on the grouping: these four all sit on the native alert evaluation path and each one alone leaves the others still misfiring, so they were integrated as one change on the target PR's branch, each kept as its own commit with you as the author. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
