feat(aci): Automatically generate names for new metric monitors

[jasonyuezhang]

Uses useSetAutomaticName to set a default title for metric monitors if the user has not edited it.

Let me know if you have wording improvements.

---

Copied from getsentry#102173
Original PR: getsentry#102173

[propel-test-bot]

Automatic naming for metric monitor creation

Introduces automatic title generation for the metric-detector workflow. A new hook useAutoMetricDetectorName constructs a human-readable monitor name from dataset, aggregate, detection type, threshold direction/value and interval, and wires it into the metric detector form. Dataset configs now expose an optional formatAggregateForTitle helper so each dataset can customise how its aggregates are verbalised (e.g. count() → "Number of errors").

Supporting changes include a typed helper getFormFieldValue, small refactors to useFormField, updated test coverage in detectors/new-setting.spec.tsx, and minor dataset-config additions for Errors, Spans, and Logs datasets.

Key Changes

• Added useAutoMetricDetectorName hook (static/app/views/detectors/components/forms/metric/useAutoMetricDetectorName.tsx) that registers useSetAutomaticName callback to compute default names for static, percent, and dynamic detection types.
• Extended dataset config interface (static/app/views/detectors/datasetConfig/base.tsx) with optional formatAggregateForTitle and implemented it for Errors, Spans, and Logs configs.
• Created generic helper getFormFieldValue and replaced direct form.getValue casts in useFormField and new code.
• Integrated auto-naming into the metric detector form (metric.tsx) and added a feature test auto-generates name in detectors/new-setting.spec.tsx.
• Updated default feature list in tests to include performance-view and adjusted expected payload name assertions.

Affected Areas

• metric detector creation UI
• Dataset config layer (errors.tsx, spans.tsx, logs.tsx, base.tsx)
• Form utilities (useFormField, new getFormFieldValue)
• E2E/react-testing spec for detectors

This summary was automatically generated by @propel-code-bot

[chatgpt-codex-connector]

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

[chatgpt-codex-connector]

Return helper as wrong generic type

The new getFormFieldValue helper is declared to return the caller‑specified generic type T, but the implementation always casts to FieldValue. Because FieldValue is only the constraint for T, this expression is not assignable to T and TypeScript will fail to compile with Type 'FieldValue' is not assignable to type 'T'. To preserve the generic typing and satisfy the compiler the value should be asserted to T instead of FieldValue.

Useful? React with 👍 / 👎.

[propel-test-bot]

[DataTypeCheck]

Type mismatch in function return type vs implementation:

export function getFormFieldValue<T extends FieldValue = FieldValue>(
  form: FormModel,
  field: string
): T {
  return form.getValue(field) as FieldValue; // ❌ Returns FieldValue, not T
}

This function promises to return type T but actually returns FieldValue, breaking type safety.

Suggested Change

Suggested change

	return form.getValue(field) as FieldValue;
	export function getFormFieldValue<T extends FieldValue = FieldValue>(
	form: FormModel,
	field: string
	): T {
	// eslint-disable-next-line @typescript-eslint/no-unnecessary-type-assertion
	return form.getValue(field) as T;
	}

⚡ Committable suggestion

Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Context for Agents

[**DataTypeCheck**]

Type mismatch in function return type vs implementation:

```typescript
export function getFormFieldValue<T extends FieldValue = FieldValue>(
  form: FormModel,
  field: string
): T {
  return form.getValue(field) as FieldValue; // ❌ Returns FieldValue, not T
}
```

This function promises to return type `T` but actually returns `FieldValue`, breaking type safety.

<details>
<summary>Suggested Change</summary>

```suggestion
export function getFormFieldValue<T extends FieldValue = FieldValue>(
  form: FormModel,
  field: string
): T {
  // eslint-disable-next-line @typescript-eslint/no-unnecessary-type-assertion
  return form.getValue(field) as T;
}
```

⚡ **Committable suggestion**

Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

</details>

File: static/app/components/workflowEngine/form/getFormFieldValue.tsx
Line: 13