feat(metric-issues): Add observed value to occurrence evidence_display

[isaacwang-sentry]

Metric issue occurrences shipped evidence_display=[] (with an XXX: may need to pass more info here for the front end note), so the value that actually breached was never exposed as curated evidence — it existed only inside the internal evidence_data payload. This is the Sentry half of the AIML-3164 work in the Autofix Support for Metric Issues project.

This emits a single important=True row:

Observed value (Number of events): 147

Why exactly one row, and why only the value

The monitor's definition — threshold, query, environment, detection type — is current detector state, served by the detector_context path (#120370 + its Seer-side rendering). The observed value is the point-in-time breach value, the one fact only the occurrence has. Duplicating the definition here would put two blocks in one LLM prompt that contradict each other as soon as a detector is edited after the occurrence was created.

One row also honors the IssueEvidence "only one important row per occurrence" convention, since space-constrained integrations surface only the first.

Two implementation details worth a look

Reading the value. build_evidence_display reads data_packet.packet.values["value"] directly rather than calling self.extract_value(), whose anomaly-detection branch wraps the result in a group-keyed dict. Both MetricUpdate variants (ProcessedSubscriptionUpdate, AnomalyDetectionUpdate) define values with a value: float key, so direct access is uniform. A test drives a real AnomalyDetectionUpdate through this path — asserting on detection_type="dynamic" in a title test would not have exercised it.

The aggregate helper returns two values. format_aggregate() is factored out of construct_title and returns (display label, normalized aggregate key). These diverge: the crash-rate branch strips the AS <CRASH_RATE_ALERT_AGGREGATE_ALIAS> suffix off the key, and it is that stripped key — not the display label — that get_alert_type_from_aggregate_dataset consumes. A display-only helper would have silently changed dynamic alert titles. The logic moved verbatim; construct_title behavior is unchanged.

Impact

• No UI change. MetricIssue.category = GroupCategory.METRIC routes to metricConfig.tsx, which sets evidence: null in _categoryDefaults and does not re-enable it for IssueType.METRIC_ISSUE, so EventEvidence returns null regardless. (metricIssueConfig.tsx serves IssueCategory.METRIC_ALERT — a different category.) Enabling that section is a separate product/design call.
• Jira ticket bodies will change — please sign off. Metric-issue actions without a metric-alert-specific handler (WEBHOOK, PLUGIN, ticketing) fall through to the generic issue-alert path, and jira/integration.py reads important_evidence_display. Slack/Discord/MSTeams/PagerDuty/Opsgenie/Email route through metric_alert_registry and are unaffected.
• Newly created occurrences only. Stored occurrences keep evidence_display=[]; there is no backfill.

Tests

tests/sentry/incidents/test_metric_issue_detector_handler.py had no evidence_display assertions — the shared verify_issue_occurrence helper checks only evidence_data. Added coverage for the row's name/value, exactly-one-important, static / comparison-delta / dynamic variants, and all four format_aggregate branches (mapped, unmapped, MRI, equation, crash-rate alias).

46 passed. Reverting evidence_display to [] fails 9 of the new tests, so they check behavior rather than restate the implementation.

🤖 Generated with Claude Code