Warn on conflicting metric identities between views matching the same instrument

[Eason09053360]

Description

Fixes #5627

MetricReaderStorage._handle_view_instrument_match warns when a new
_ViewInstrumentMatch conflicts with an existing one ("Views ... will cause
conflicting metrics identities"), but the check only scans
self._instrument_view_instrument_matches.values() — the matches of
previously registered instruments. The list being built for the current
instrument is written to that dict only after every view has been processed,
so two views matching the same instrument with identical stream identities
were never compared: both streams were exported under the same name in one
payload and nothing was logged.

reader = InMemoryMetricReader()
mp = MeterProvider(
    metric_readers=[reader],
    views=[
        View(instrument_name="requests", attribute_keys={"path"}),
        View(instrument_name="requests", attribute_keys={"method"}),
    ],
)
mp.get_meter("m").create_counter("requests").add(1, {"path": "/a", "method": "GET"})

md = reader.get_metrics_data()
print([m.name for m in md.resource_metrics[0].scope_metrics[0].metrics])
# ['requests', 'requests'] — duplicate identity, no warning

The spec requires the warning
(sdk.md#view):

If applying the View results in conflicting metric identities the
implementation SHOULD apply the View and emit a warning.

The same conflict split across two instruments (View(instrument_name="c1", name="foo") + View(instrument_name="c2", name="foo")) already warned, so
only the same-instrument path was affected.

This PR includes the in-progress match list in the conflict scan. It also
excludes drop-aggregation matches from conflicts(): dropped streams are never
exported (collect() skips _DropAggregation), so layered drop views such as
View("http.client.*", aggregation=DropAggregation()) +
View("*", aggregation=DropAggregation()) must not trigger the warning.

Out of scope, tracked in #5629: the _DEFAULT_VIEW fallback path still
appends its match without a conflict check, so a view-renamed stream colliding
with a default-view stream is only reported in one registration order.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• New test_view_instrument_match_conflict_9: two views on the same
  instrument with identical identity → warning (fails without the fix with
  no logs of level WARNING).
• New test_view_instrument_match_conflict_10: two views on the same
  instrument with different names → no warning.
• New test_view_instrument_match_conflict_11: two overlapping drop views on
  the same instrument → no warning.
• test_creates_view_instrument_matches and
  test_forwards_calls_to_view_instrument_match now assert the warning that
  their mocked conflicts() (a truthy Mock) triggers on the first
  measurement, matching how they already handled the cross-instrument case.
• opentelemetry-sdk/tests/metrics/ — 334 passed, 1 skipped.

Does This PR Require a Contrib Repo Change?

• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on reviewers · refreshed 2026-09-05 14:20 UTC

Review the latest changes.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.