Summary

Closes #6567

Extends the deduplication rule model with a rule_type field (split | correlate) to support correlating related alerts across different fingerprints — without merging them or losing per-alert detail.

What changed

• AlertDeduplicationRule gains a rule_type field:

Each provider can have one rule of each type simultaneously.

• New fields on AlertDto

Pipeline

incoming alert
      │
      ▼
format_alert (base_provider.py)
  ├─ split rule?  → recompute alert.fingerprint
  └─ correlate rule? → compute alert.correlation_fingerprint
      │
      ▼
apply_deduplication (alert_deduplicator.py)
  ├─ split check: is fingerprint already in LastAlert? → isFullDuplicate / isPartialDuplicate
  └─ correlate check: is correlation_fingerprint already in LastAlert?
       → alert.is_correlated = True
       → alert.correlated_to = representative fingerprint
      │
      ▼
save to DB
  └─ set_last_alert stores correlation_fingerprint on LastAlert row

Files changed

• DB models: rule_type on deduplication rules; correlation_fingerprint (indexed) on last alerts
• Alert DTO: new correlation_fingerprint, is_correlated, and correlated_to fields
• Deduplication pipeline: correlate rule applied in format step; correlation check sets is_correlated/correlated_to before save
• DB helpers: lookup and persistence of correlation_fingerprint
• Migrations: rule_type column (existing rules default to split); correlation_fingerprint column on last alerts
• Frontend: rule_type support with a split/correlate selector and conflict detection

Migration notes

All existing custom deduplication rules are migrated to rule_type="split" — this is correct because the original purpose of the feature was exclusively to control fingerprint computation (alert identity).

Action required after deploying: Review your existing custom rules. If any rule was created with the intent of correlating related alerts (e.g., grouping pod instances), change its rule_type to "correlate" via the UI.

Usage example

Goal: The same alert fires on multiple instances simultaneously. Each instance alert should be stored individually, but only one notification should fire per group.

Split rule (controls identity — keep existing):

• fingerprint_fields: [fingerprint, startsAt]
• Type: Split

Correlate rule (new):

• fingerprint_fields: [alertname, service]
• Type: Correlate

Workflow condition (only notify for the representative alert):

filters:
  - key: is_correlated
    value: "false"