[🐛 Bug]: Topology Correlation not working

[Angstfw]

Describe the bug
Topology-based incidents are not created correctly by the topology processor.
When the processor tries to create a new incident for an application and attach alerts to it, it fails with a PostgreSQL foreign key violation on lastalerttoincident.incident_id → incident.id.

To Reproduce
Steps to reproduce the behavior:

1. In a clean Keep instance, create two services in the topology and attach an application to them (as in the screenshot).

2. Send test alerts with the following contents.
   alert 1:

{
  "id": "2c3e7695-c890-45f8-878a-5e6927ed7aad",
  "name": "KeepCorrelationTest1 - ha-proxy-1 - 2",
  "status": "firing",
  "severity": "critical",
  "lastReceived": "2025-12-01T10:54:53.362Z",
  "firingStartTime": "2025-12-01T10:54:53.362Z",
  "firingStartTimeSinceLastResolved": "2025-12-01T10:54:53.362Z",
  "firingCounter": 1,
  "unresolvedCounter": 1,
  "environment": "unknown",
  "isFullDuplicate": false,
  "isPartialDuplicate": false,
  "duplicateReason": null,
  "service": "ha-proxy-1",
  "source": [
    "victoriametrics"
  ],
  "apiKeyRef": "webhook",
  "message": null,
  "description": "Test alert to reproduce correlation rules based on job label",
  "description_format": null,
  "pushed": true,
  "event_id": "6655fd06-00a2-4f59-9732-d6947170cb0c",
  "url": "http://example.local/vmalert/alert?group_id=1&alert_id=1",
  "imageUrl": null,
  "labels": {
    "alertname": "KeepCorrelationTest1 - ha-proxy-1 - 2",
    "severity": "critical",
    "alertgroup": "topology-test",
    "namespace": "keep-correlation-test",
    "pod": "keep-correlation-test-1",
    "send_keep": "keep",
    "job": "ha-proxy-1"
  },
  "fingerprint": "c0ca3127d3dd4fd66318a19dde304bb4681e9d7c126978173f6bf62705c5489d",
  "deleted": false,
  "dismissUntil": null,
  "dismissed": false,
  "assignee": null,
  "providerId": null,
  "providerType": "victoriametrics",
  "note": null,
  "startedAt": "2025-12-01T07:28:31.788Z",
  "isNoisy": false,
  "incident": null,
  "updated_at": "2025-12-01 10:30:02.073248+00:00",
  "alert_hash": "3395dab1f9d14ad705d356755502fefb4cdabc640b75c33810dd7dc7fb2df5fb",
  "firstTimestamp": "2025-12-01 10:54:53.408000",
  "display_name": "ha-proxy-1",
  "source_provider_id": "unknown",
  "is_manual": true
}

alert 2:

{
  "id": "bebcc218-8efb-4e89-a701-95bf4b9446ac",
  "name": "KeepCorrelationTest1 - db-1 - 2",
  "status": "firing",
  "severity": "warning",
  "lastReceived": "2025-12-01T10:54:56.925Z",
  "firingStartTime": "2025-12-01T10:54:56.925Z",
  "firingStartTimeSinceLastResolved": "2025-12-01T10:54:56.925Z",
  "firingCounter": 1,
  "unresolvedCounter": 1,
  "environment": "unknown",
  "isFullDuplicate": false,
  "isPartialDuplicate": false,
  "duplicateReason": null,
  "service": "db-1",
  "source": [
    "victoriametrics"
  ],
  "apiKeyRef": "webhook",
  "message": null,
  "description": "Test alert to reproduce correlation rules based on job label",
  "description_format": null,
  "pushed": true,
  "event_id": "b27b44d3-8ffb-4997-af7f-4c4dcb3410af",
  "url": "http://example.local/vmalert/alert?group_id=1&alert_id=1",
  "imageUrl": null,
  "labels": {
    "alertname": "KeepCorrelationTest1 - db-1 - 2",
    "severity": "warning",
    "alertgroup": "topology-test",
    "namespace": "keep-correlation-test",
    "pod": "keep-correlation-test-1",
    "send_keep": "keep",
    "job": "db-1"
  },
  "fingerprint": "65ed76f313b5322f88ce5e080871df714ac85ac36f664c65a7ba442676758ffd",
  "deleted": false,
  "dismissUntil": null,
  "dismissed": false,
  "assignee": null,
  "providerId": null,
  "providerType": "victoriametrics",
  "note": null,
  "startedAt": "2025-12-01T07:28:31.788Z",
  "isNoisy": false,
  "incident": null,
  "updated_at": "2025-12-01 10:28:26.035480+00:00",
  "alert_hash": "c953c615c38c10ab8150210a3d38dc12d5fd8cd35a272a8bf654ac8f190ce7ee",
  "firstTimestamp": "2025-12-01 10:54:56.964000",
  "display_name": "db-1",
  "source_provider_id": "unknown",
  "is_manual": true
}

Expected behavior
An incident containing both alerts should appear.

Additional context
I am attaching the backend log.

keep-backend.log

[dosubot]

This is a known bug in the topology processor: it tries to link alerts to a new incident before the incident is actually persisted in the database, which causes the PostgreSQL foreign key violation you’re seeing. The incident object is created in memory, but not added to the session or committed before assign_alert_to_incident (and thus add_alerts_to_incident) is called, so the incident.id doesn’t exist in the database when LastAlertToIncident rows are inserted. The correct sequence is to add and commit the incident to the session before linking alerts, ensuring the incident.id is valid for foreign key references. This issue is tracked and discussed in issue #4816, and a fix is planned to adjust the order of operations in the topology processor.

To resolve this, review the incident creation logic and make sure the incident is persisted before any alert-to-incident linking occurs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}