[🐛 Bug]: Missing explicit `is_predicted=True` when creating topology based incident

[PrometheRus]

Describe the bug

In keep/topologies/topology_processor.py, when creating an Incident with incident_type="topology" , the is_predicted flag is not set. In the ORM model (keep/api/models/db/incident.py), this field defaults to False.

Because of this, topology incidents are incorrectly marked as unpredicted, even though they are, in fact, the result of correlation analysis based on service topology.

To Reproduce

1. Open keep/topologies/topology_processor.py.
2. Check the Incident constructor call in _create_application_based_incident.
3. Observe that is_predicted is absent, while is_visible=True and is_candidate=False are present.
4. Check keep/api/models/db/incident.py — is_predicted defaults to False.

Expected behavior
When creating a topological incident, is_predicted=True must be explicitly specified, since the incident is generated algorithmically based on the topological dependency of services, and not by the direct triggering of a custom alert or rule.

Screenshots

Additional context

Version: 0.51.0 | Build: 0cfb50

[dosubot]

I can confirm this bug. In _create_application_based_incident [1], the Incident is created without setting is_predicted, so it defaults to False [2].

For comparison, both the AI correlation path in ai_suggestion_bl.py [3] and the rule-based grouping path in db.py [4] explicitly set is_predicted=True when creating automated/algorithmic incidents.

The fix would be straightforward — adding is_predicted=True to the Incident constructor in topology_processor.py:

incident = Incident(
    tenant_id=tenant_id,
    user_generated_name=f"Application incident: {application.name}",
    user_summary=f"Multiple services in application {application.name} are experiencing issues",
    incident_type="topology",
    incident_application=application.id,
    is_candidate=False,
    is_visible=True,
    is_predicted=True,  # Topology-based incidents are algorithmically generated
)

This aligns topology incidents with the existing convention for system-generated incidents.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.