Problem

Currently OM/Text (not proto!) Type Unit and Help parser methods can yield wrong metadata (belonging to a different metric family) for text formats for the cases like this (unknown metadata):

# TYPE test_metric3 gauge
# HELP test_metric3 this represents tricky case of "broken" text that is not trivial to detect.
test_metric3_metric4{foo="bar"} 2

Text and OM parsers would return # TYPE test_metric3 gauge metadata for test_metric3_metric4 series.

This is reflected by the following unit tests: https://github.com/prometheus/prometheus/blob/main/model/textparse/promparse_test.go#L56

This functionally impacts:

• Metadata API
• type-and-unit-labels

We try to mitigate this problem for metadata-wal-records feature with the funky isSeriesPartOfFamily, but it's quite expensive (you need to find name and check trillion suffixes).

It's getting bit more expensive for AppenderV2 flow too for metadata-wal-records: #17867 (comment)

NOTE: This path will be also cheaper with OpenMetrics 2.0 because of metric family == metric name notion.

Acceptance Criteria

• Handle this text/OM1 case in the text and OM parser.