Skip to content

Conversation

@ThomsonTan
Copy link
Contributor

@ThomsonTan ThomsonTan commented Oct 31, 2025

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.md updated for non-trivial changes
  • Unit tests have been added
  • Changes in public API reviewed

@ThomsonTan ThomsonTan requested a review from a team as a code owner October 31, 2025 00:50
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment on lines 47 to 60
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;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Copy link
Contributor Author

@ThomsonTan ThomsonTan Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

codecov bot commented Oct 31, 2025

Codecov Report

❌ Patch coverage is 65.51724% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.90%. Comparing base (d37c579) to head (c1c5d0a).

Files with missing lines Patch % Lines
...ude/opentelemetry/sdk/metrics/view/view_registry.h 68.00% 8 Missing ⚠️
...metry/sdk/metrics/aggregation/aggregation_config.h 50.00% 2 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            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     
Files with missing lines Coverage Δ
sdk/include/opentelemetry/sdk/metrics/view/view.h 100.00% <ø> (ø)
...metry/sdk/metrics/aggregation/aggregation_config.h 89.48% <50.00%> (-10.52%) ⬇️
...ude/opentelemetry/sdk/metrics/view/view_registry.h 82.76% <68.00%> (-11.18%) ⬇️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ThomsonTan ThomsonTan changed the title Add tag to AggregationConfig for aggregation type validation [Metrics] Add tag to AggregationConfig for aggregation type validation Oct 31, 2025
attributes_processor_{std::move(attributes_processor)}
{}
{
// Validate that aggregation_type and aggregation_config match
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that aggregation_config contains its proper type, can the aggregation_type parameter be removed instead ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not for now because the common AggregationConfig can still handle multiple aggregation types, like kDefault, kSum, etc. It is not 1:1 mapping.

Copy link
Member

@marcalff marcalff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See some simplification.

@Reneg973
Copy link
Contributor

I guess also here exceptions are not allowed.
You could also add a noexcept where it's missing.

@ThomsonTan
Copy link
Contributor Author

I guess also here exceptions are not allowed. You could also add a noexcept where it's missing.

@Reneg973 , where do add the noexcept, the View constructor?

@Reneg973
Copy link
Contributor

Reneg973 commented Nov 1, 2025

I guess also here exceptions are not allowed. You could also add a noexcept where it's missing.

@Reneg973 , where do add the noexcept, the View constructor?

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();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, someone defines a wrong view, and the process dies ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If exception is not allowed, currently yes, the process dies.

@ThomsonTan ThomsonTan added the pr:please-review This PR is ready for review label Nov 6, 2025

default:
// Unreachable: all AggregationType enum values are handled above
std::abort();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@marcalff marcalff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For robustness, ignore invalid views / instruments / aggregations / etc.

A broken aggregation definition should not kill the application.

Comment on lines 54 to 60
{
#if defined(__cpp_exceptions)
throw std::invalid_argument("instrument_selector, meter_selector, and view cannot be null");
#else
std::abort();
#endif
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced throw/abort with internal error log and ignores it.

@ThomsonTan ThomsonTan changed the title [Metrics] Add tag to AggregationConfig for aggregation type validation [METRICS] Add tag to AggregationConfig for aggregation type validation Nov 10, 2025
#pragma once

#include <memory>
#include <stdexcept>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not needed, to remove.


default:
// Unreachable: all AggregationType enum values are handled above
std::abort();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assert(false) instead ?

When building in release mode, should that path ever be seen, the code will fall gracefully with valid = false and an error in the log.

Copy link
Member

@marcalff marcalff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, see minor cleanup.

@marcalff
Copy link
Member

@codex review

@chatgpt-codex-connector
Copy link

To use Codex here, create a Codex account and connect to github.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr:please-review This PR is ready for review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Mismatch between AggregationConfig and AggregationType in View constructor could cause memory corruption

4 participants