Hash collision risk of metric data aggregation

[alangy98]

Hello, I have concerns regarding the hash collision issue with the current implementation of metric data aggregation, related to this PR #1993.

opentelemetry-cpp/sdk/include/opentelemetry/sdk/metrics/state/attributes_hashmap.h

Line 201 in c6d3945

std::unordered_map<size_t, std::pair<MetricAttributes, std::unique_ptr<Aggregation>>> hash_map_;

The aggregation map uses size_t as the key type, and the hash code of the attribute set is treated as a unique identifier. However, if two different attribute sets happen to generate the same hash code, it could lead to collisions, and I haven’t seen any handling for this scenario in the current logic.

Why not consider using the MetricAttributes instead of its hash code as the key of the unordered_map?

Thanks

[lalitb]

@alangy98 The original purpose of the custom hash function was to guarantee that we generate the same hash code regardless of the order in which the user provides the attributes, without needing to sort them. Additionally, it was designed to retain the hash code to prevent recalculating it repeatedly. I agree that we should address the collision handling logic here. If you're interested in contributing, feel free to proceed; otherwise, I can take a look at this later.

[github-actions]

This issue was marked as stale due to lack of activity.