Use typed detector schemas from @sentry/api for metric monitors #1595

@sentry/api leaves the detector (monitor) payloads mostly untyped. Because of that, toolkit has to keep its own copy of the metric monitor data source and condition values.

Checked against @sentry/api 0.381.0, the latest release. The CLI pins ^0.356.0 and mcp-core pins 0.337.0.

Gaps in types.gen.d.ts

• Create/UpdateOrganizationDetectorData: data_sources?: Array<unknown> and condition_group.conditions?: Array<unknown>. config is { [key: string]: unknown }.
• GetOrganizationDetectorResponses[200]: dataSources, conditionGroup, and config are all { [key: string]: unknown }.
• The accepted values appear only in doc comments: dataset, queryType, eventTypes, timeWindow, condition type/comparison/conditionResult, and detectionType/comparisonDelta. The generated zod and valibot schemas have the same gaps.

Workaround today
#1591 adds @sentry/toolkit-core/metric-monitor. It hand-copies these values from Sentry's SnubaQueryValidator (QUERY_TYPE_VALID_DATASETS / QUERY_TYPE_VALID_EVENT_TYPES) and MetricIssueComparisonConditionValidator. The CLI (packages/cli/src/types/metric-alert.ts, packages/cli/src/lib/api/alerts.ts) and MCP (packages/mcp-core/src/tools/support/metric-monitor-config.ts) both consume that module and cast detector bodies through unknown.

Ask

• Get typed detector schemas into @sentry/api, likely by adding typed serializers or validators for the detector endpoints in getsentry/sentry so the generated OpenAPI spec carries them:
  • a snuba-query data source (dataset / queryType / eventTypes enums)
  • metric comparison and anomaly conditions
  • detection config
• Once those land, swap @sentry/toolkit-core/metric-monitor and the CLI/MCP casts for the generated types and schemas, and bump @sentry/api in both packages.

Raised by @BYK in review on #1591.

via BYK.

--

View Junior Session [Sentry]