fix: delete TopologyServiceApplication links before TopologyService rows (fixes #5439)

[chengyixu]

Summary

Fixes a ForeignKeyViolation that crashes process_topology whenever a provider's topology services belong to a TopologyApplication.

Root cause

process_topology refreshes topology data by deleting then re-inserting all TopologyService rows for a given provider. The deletion order was:

1. Delete TopologyServiceDependency (correct — has CASCADE)
2. Delete TopologyService (fails when a row is still referenced by TopologyServiceApplication.service_id)

The TopologyServiceApplication join table does not have ON DELETE CASCADE, so step 2 raised:

sqlalchemy.exc.IntegrityError: ForeignKeyViolation:
update or delete on table "topologyservice" violates
foreign key constraint "topologyserviceapplication_service_id_fkey"

This is the exact traceback reported in #5439.

Fix

Delete the TopologyServiceApplication rows for the affected services before deleting the TopologyService rows, using the same filter pattern already used for TopologyServiceDependency.

Changes

• keep/api/tasks/process_topology_task.py — add TopologyServiceApplication deletion step
• tests/test_topology.py — regression test that would have caught this (and confirms the fix)

Closes #5439

/claim #5439

[vercel]

@chengyixu is attempting to deploy a commit to the KeepHQ Team on Vercel.

A member of the Team first needs to authorize it.

[chengyixu]

Hi team! This fixes the ForeignKeyViolation crash in process_topology (#5439). All CI checks passing. Happy to address any feedback!

[chengyixu]

Friendly ping — this fix addresses the ForeignKeyViolation crash in process_topology when deleting topology services (issue #5439). All CI checks pass. Happy to adjust anything if needed!

[chengyixu]

Hi team — gentle ping. This PR fixes the ForeignKeyViolation crash in process_topology when deleting topology services (issue #5439). All CI checks passing. Happy to adjust anything if needed!

[chengyixu]

Hi team — friendly ping on this fix for the ForeignKeyViolation crash in process_topology (issue #5439). Deletes TopologyServiceApplication links before TopologyService rows. All CI checks passing. Happy to address any feedback!

[chengyixu]

Friendly ping @keephq/maintainers -- this PR has been open for 37 days. It fixes a foreign key constraint issue by deleting TopologyServiceApplication links before TopologyService rows (fixes #5439). Is there anything else needed before review? Thanks!

[chengyixu]

👋 Friendly ping — this PR has been open for 37 days with all checks passing. Is there anything else needed for review? Thanks!

[chengyixu]

Hi maintainers, just a friendly ping on this PR. It's been open for a while — would love a review when you have a moment. Happy to rebase or make any changes needed. Thanks!

[chengyixu]

Hi! This PR is CI green and ready for merge when you have a moment. Thanks!

[ayoubil]

Strong fix for the immediate symptom. One observation worth flagging for defense-in-depth, since this issue keeps coming up:

The root cause is that TopologyServiceApplication was defined in keep/api/models/db/topology.py without ondelete="CASCADE" on either FK:

class TopologyServiceApplication(SQLModel, table=True):
    service_id:     int  = Field(foreign_key="topologyservice.id",     primary_key=True)
    application_id: UUID = Field(foreign_key="topologyapplication.id", primary_key=True)

Compare with how alerttoincident was set up in migration 0832e0d9889a, where both columns get ondelete="CASCADE". That table never has this class of bug.

The app-layer ordering fix in this PR is correct and unblocks #5439, but any other code path that ever does session.delete(topology_service) or executes a bulk TopologyService delete query will reintroduce the same ForeignKeyViolation. A follow-up that adds ondelete="CASCADE" to both FKs (model + alembic migration to alter the existing constraint) would close the door on the entire bug class.

Happy to submit that schema-level follow-up if you'd like, once this lands — wanted to call it out here so it doesn't get lost.

[chengyixu]

Thanks for the thorough review, @ayoubil! Great catch on the missing ondelete="CASCADE" -- that is the real root cause.

I agree the app-layer ordering fix in this PR is correct and unblocks #5439, but the schema-level fix would close the door permanently. I am happy to submit the CASCADE follow-up PR right after this lands:

1. Add ondelete="CASCADE" to both FKs in TopologyServiceApplication
2. Add a matching alembic migration to alter the existing constraints

Would you prefer I add the CASCADE changes to this PR now, or submit them as a separate follow-up once this one merges? Either way works for me.

Thanks again for the detailed review!

[chengyixu]

Pushed the CASCADE follow-up as discussed @ayoubil:

1. Added ondelete="CASCADE" to both FKs in TopologyServiceApplication (model)
2. Added alembic migration to alter the existing FK constraints with ON DELETE CASCADE

This closes the door on the entire FK violation bug class. The app-layer ordering fix is still in place as added safety.