keep icon indicating copy to clipboard operation
keep copied to clipboard

[šŸ› Bug]: argocd topology pull error

Open Viste opened this issue 3 months ago • 1 comments

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

  1. Go to providers add argocd
  2. wait a bit
  3. then you get error in logs: {"worker_type": "uvicorn", "asctime": "2025-11-11 03:18:19,343", "message": "Unknown error pulling topology from provider argocd (b3c524d329144dc58a474a0fb4a91355)", "levelname": "ERROR", "name": "keep.api.routes.preset", "filename": "preset.py", "otelTraceID": "99a04b33f8c0b59e744c4568399b7c36", "otelSpanID": "d7f244aa745a3ac7", "otelTraceSampled": true, "otelServiceName": "keep-api", "threadName": "AnyIO worker thread", "process": 54, "module": "preset", "exc_info": "Traceback (most recent call last):\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/base.py\", line 1967, in _exec_single_context\n self.dialect.do_execute(\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/default.py\", line 941, in do_execute\n cursor.execute(statement, parameters)\npsycopg2.errors.ForeignKeyViolation: update or delete on table \"topologyservice\" violates foreign key constraint \"topologyserviceapplication_service_id_fkey\" on table \"topologyserviceapplication\"\nDETAIL: Key (id)=(1805) is still referenced from table \"topologyserviceapplication\".\n\n\nThe above exception was the direct cause of the following exception:\n\nTraceback (most recent call last):\n File \"/venv/lib/python3.11/site-packages/keep/api/routes/preset.py\", line 159, in pull_data_from_providers\n process_topology(\n File \"/venv/lib/python3.11/site-packages/keep/api/tasks/process_topology_task.py\", line 59, in process_topology\n ).delete()\n ^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/orm/query.py\", line 3162, in delete\n result: CursorResult[Any] = self.session.execute(\n ^^^^^^^^^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlmodel/orm/session.py\", line 127, in execute\n return super().execute(\n ^^^^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/orm/session.py\", line 2362, in execute\n return self._execute_internal(\n ^^^^^^^^^^^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/orm/session.py\", line 2247, in _execute_internal\n result: Result[Any] = compile_state_cls.orm_execute_statement(\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/orm/bulk_persistence.py\", line 2021, in orm_execute_statement\n return super().orm_execute_statement(\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/orm/context.py\", line 305, in orm_execute_statement\n result = conn.execute(\n ^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/base.py\", line 1418, in execute\n return meth(\n ^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/sql/elements.py\", line 515, in _execute_on_connection\n return connection._execute_clauseelement(\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/base.py\", line 1640, in _execute_clauseelement\n ret = self._execute_context(\n ^^^^^^^^^^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/base.py\", line 1846, in _execute_context\n return self._exec_single_context(\n ^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/base.py\", line 1986, in _exec_single_context\n self._handle_dbapi_exception(\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/base.py\", line 2355, in _handle_dbapi_exception\n raise sqlalchemy_exception.with_traceback(exc_info[2]) from e\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/base.py\", line 1967, in _exec_single_context\n self.dialect.do_execute(\n File \"/venv/lib/python3.11/site-packages/sqlalchemy/engine/default.py\", line 941, in do_execute\n cursor.execute(statement, parameters)\nsqlalchemy.exc.IntegrityError: (psycopg2.errors.ForeignKeyViolation) update or delete on table \"topologyservice\" violates foreign key constraint \"topologyserviceapplication_service_id_fkey\" on table \"topologyserviceapplication\"\nDETAIL: Key (id)=(1805) is still referenced from table \"topologyserviceapplication\".\n\n[SQL: DELETE FROM topologyservice WHERE topologyservice.source_provider_id = %(source_provider_id_1)s AND topologyservice.tenant_id = %(tenant_id_1)s /*db_driver='psycopg2',db_framework='sqlalchemy%%3A2.0.36',traceparent='00-99a04b33f8c0b59e744c4568399b7c36-d71f45aa5b93a741-01'*/]\n[parameters: {'source_provider_id_1': 'b3c524d329144dc58a474a0fb4a91355', 'tenant_id_1': 'keep'}]\n(Background on this error at: https://sqlalche.me/e/20/gkpj)", "provider_type": "argocd", "provider_id": "b3c524d329144dc58a474a0fb4a91355", "tenant_id": "keep", "trace_id": "99a04b33f8c0b59e744c4568399b7c36", "exception": "(psycopg2.errors.ForeignKeyViolation) update or delete on table \"topologyservice\" violates foreign key constraint \"topologyserviceapplication_service_id_fkey\" on table \"topologyserviceapplication\"\nDETAIL: Key (id)=(1805) is still referenced from table \"topologyserviceapplication\".\n\n[SQL: DELETE FROM topologyservice WHERE topologyservice.source_provider_id = %(source_provider_id_1)s AND topologyservice.tenant_id = %(tenant_id_1)s /*db_driver='psycopg2',db_framework='sqlalchemy%%3A2.0.36',traceparent='00-99a04b33f8c0b59e744c4568399b7c36-d71f45aa5b93a741-01'*/]\n[parameters: {'source_provider_id_1': 'b3c524d329144dc58a474a0fb4a91355', 'tenant_id_1': 'keep'}]\n(Background on this error at: https://sqlalche.me/e/20/gkpj)"}

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here.

Viste avatar Nov 11 '25 09:11 Viste

Hi @Viste! I'm Dosu and I’m helping the keep team.

The error happens because the code tries to delete rows from the topologyservice table while there are still references to those rows in topologyserviceapplication, violating the foreign key constraint. The schema does not use ON DELETE CASCADE for this relationship, so the database blocks the delete to maintain referential integrity. To fix this, you can either manually delete all related topologyserviceapplication rows before deleting from topologyservice, or update the migration and model to add ON DELETE CASCADE to the foreign key constraint so dependent rows are automatically removed when a service is deleted. The correct deletion order is to remove dependencies, then service-application links, then services themselves. More details and a suggested schema migration are available in this discussion and this related thread.

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report šŸ› | OtherĀ Ā Chat with DosuĀ Join DiscordĀ Share on X

dosubot[bot] avatar Nov 11 '25 09:11 dosubot[bot]