Closed yangjian closed 5 months ago
I would like to understand the use case for this change, whyy the need to inherit AttributeProcessor instead of extending it
There're common labels for all metrics in our iOS app. Attribute processor can be used to merge them into final labels. But one of these labels can be changed by user or server. Customized attribute processor can be more flexible to support it. Something like this:
class GlobalSharedLabels: AttributeProcessor {
let attributes: ManagedAtomic<AtomicContainer<[String: AttributeValue]>>
public updateLabels(...) {
attributes.store(...)
}
public func process(incoming: [String: AttributeValue]) -> [String: AttributeValue] {
incoming.merging(attributes.load(...), uniquingKeysWith: { $1 })
}
}
Alternatively, it can return a SimpleAttributeProcessor
, but it isn't exported before.
Attention: Patch coverage is 69.23077%
with 8 lines
in your changes are missing coverage. Please review.
:exclamation: No coverage uploaded for pull request base (
main@4d1502b
). Click here to learn what that means.
Files | Patch % | Lines |
---|---|---|
...TelemetrySdk/Metrics/Stable/View/ViewBuilder.swift | 0.00% | 5 Missing :warning: |
...rySdk/Metrics/Stable/View/AttributeProcessor.swift | 85.71% | 3 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Previously AttribtueProcessor is a class and not open. It can't be customized externally. Now it's changed to procotol and its static functions are moved into SimpleAttributeProcessor (now it's public).
Also duplicated NoopAttributesProcessor is removed and more tests are added.