[METRICS] Add tag to AggregationConfig for aggregation type validation#3732
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| switch (aggregation_type_) | ||
| { | ||
| case AggregationType::kHistogram: | ||
| valid = (config_type == AggregationConfigType::kHistogram); | ||
| break; | ||
| case AggregationType::kBase2ExponentialHistogram: | ||
| valid = (config_type == AggregationConfigType::kBase2ExponentialHistogram); | ||
| break; | ||
| case AggregationType::kDefault: | ||
| case AggregationType::kDrop: | ||
| case AggregationType::kLastValue: | ||
| case AggregationType::kSum: | ||
| valid = (config_type == AggregationConfigType::kDefault); | ||
| break; |
There was a problem hiding this comment.
Allow histogram configs when aggregation type is default
The new validation in View now throws whenever AggregationType::kDefault is paired with a HistogramAggregationConfig. However, kDefault defers the actual aggregation choice to the instrument’s default (GetDefaultAggregationType returns kHistogram for histogram instruments). Existing callers can legitimately pass a histogram config while leaving the aggregation type at kDefault to customize bucket boundaries without overriding the default type; this change will now throw std::invalid_argument and prevent those views from being constructed. The check should accept histogram (and other concrete) config types when aggregation_type_ is kDefault because the concrete aggregation is resolved later based on the instrument descriptor.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
The check is moved to ViweRegistry::AddView, to the deferred handling of kDefault logic is copied there. This is possible because AddView has both AggregationConfig and InstrumentationSelector.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3732 +/- ##
==========================================
- Coverage 90.01% 89.90% -0.11%
==========================================
Files 225 225
Lines 7105 7134 +29
==========================================
+ Hits 6395 6413 +18
- Misses 710 721 +11
🚀 New features to boost your workflow:
|
| attributes_processor_{std::move(attributes_processor)} | ||
| {} | ||
| { | ||
| // Validate that aggregation_type and aggregation_config match |
There was a problem hiding this comment.
Now that aggregation_config contains its proper type, can the aggregation_type parameter be removed instead ?
There was a problem hiding this comment.
Probably not for now because the common AggregationConfig can still handle multiple aggregation types, like kDefault, kSum, etc. It is not 1:1 mapping.
|
I guess also here exceptions are not allowed. |
@Reneg973 , where do add the |
On every function, also constructor, like this: virtual AggregationType GetType() const noexcept { return AggregationType::kDefault; } |
| #if defined(__cpp_exceptions) | ||
| throw std::invalid_argument("AggregationType and AggregationConfig type mismatch"); | ||
| #else | ||
| std::abort(); |
There was a problem hiding this comment.
So, someone defines a wrong view, and the process dies ?
There was a problem hiding this comment.
If exception is not allowed, currently yes, the process dies.
|
|
||
| default: | ||
| // Unreachable: all AggregationType enum values are handled above | ||
| std::abort(); |
There was a problem hiding this comment.
nit - this can be a utility method say IsDefaultAggregation(agg_type, inst_type, is_monotinic) in default_aggregation.h, but can be done afterwards if required at other places.
marcalff
left a comment
There was a problem hiding this comment.
For robustness, ignore invalid views / instruments / aggregations / etc.
A broken aggregation definition should not kill the application.
| { | ||
| #if defined(__cpp_exceptions) | ||
| throw std::invalid_argument("instrument_selector, meter_selector, and view cannot be null"); | ||
| #else | ||
| std::abort(); | ||
| #endif | ||
| } |
There was a problem hiding this comment.
For every other failures in general, like illegal instrument names, the code just logs an error and ignores the instrument / view.
We should not throw exceptions or worse kill the process here, only ignore invalid configuration.
There was a problem hiding this comment.
Replaced throw/abort with internal error log and ignores it.
|
@codex review |
|
To use Codex here, create a Codex account and connect to github. |
|
The CI failure in install tests (conan) is due to a file system full on the github runner. See: My take is that we still should merge this PR, the same failure exists in main already. |
Fixes #3731
Changes
Please provide a brief description of the changes here.
For significant contributions please make sure you have completed the following items:
CHANGELOG.mdupdated for non-trivial changes