Bug description
With Superset 4.0.1, I create lots of dashbaords, sometimes, dashboard could not be deleted
The dashborad is empty but I can't delete it :
Screenshots/recordings
No response
Superset version
master / latest-dev
Python version
3.9
Node version
16
Browser
Chrome
Additional context
No response
Checklist
- [ ] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [ ] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: dosubot[bot]
I did not find any existing issues or discussions specifically about dashboards sometimes not being deletable in Superset 4.0.1. The dashboard deletion process is handled in the backend by the delete function in superset/dashboards/api.py, which uses the DeleteDashboardCommand. This function can fail and prevent deletion if certain exceptions are raised, such as DashboardNotFoundError, DashboardForbiddenError, or DashboardDeleteFailedError—these would typically be logged as errors in your Superset logs if encountered during a delete attempt. Reviewing your logs for these specific errors may help pinpoint the cause of the failure in your case. You can see the relevant code and exception handling here.
There was also a migration script added to implement "on delete cascade" for embedded dashboards, which could affect dashboard deletion if there are related embedded dashboard records. If your dashboards are linked to embedded dashboards, this relationship might be preventing deletion in some cases. You can review the migration logic here.
If you are not seeing any errors in your logs, or if the dashboard is not linked to any embedded dashboards, it may help to provide any error messages or stack traces you find for further troubleshooting.
To reply, just mention my name @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
Comment From: xavier-GitHub76
DELETE statement on table 'tagged_object' expected to delete 2 row(s); Only 4 were matched. Traceback (most recent call last): File "/app/superset/daos/base.py", line 217, in delete db.session.commit() File "", line 2, in commit File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/session.py", line 1435, in commit self._transaction.commit(_to_root=self.future) File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/session.py", line 829, in commit self._prepare_impl() File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/session.py", line 808, in _prepare_impl self.session.flush() File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/session.py", line 3367, in flush self._flush(objects) File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/session.py", line 3507, in flush transaction.rollback(capture_exception=True) File "/usr/local/lib/python3.9/site-packages/sqlalchemy/util/langhelpers.py", line 70, in exit compat.raise( File "/usr/local/lib/python3.9/site-packages/sqlalchemy/util/compat.py", line 207, in raise raise exception File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/session.py", line 3467, in _flush flush_context.execute() File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/unitofwork.py", line 456, in execute rec.execute(self) File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/unitofwork.py", line 577, in execute self.dependency_processor.process_deletes(uow, states) File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/dependency.py", line 1110, in process_deletes self._run_crud( File "/usr/local/lib/python3.9/site-packages/sqlalchemy/orm/dependency.py", line 1207, in _run_crud raise exc.StaleDataError( sqlalchemy.orm.exc.StaleDataError: DELETE statement on table 'tagged_object' expected to delete 2 row(s); Only 4 were matched
Comment From: dosubot[bot]
The error you're seeing—StaleDataError: DELETE statement on table 'tagged_object' expected to delete 2 row(s); Only 4 were matched—indicates a data consistency issue in the tagged_object table. This happens when SQLAlchemy expects to delete a certain number of rows (based on its session state), but the actual number of rows affected in the database is different. This often points to duplicate or orphaned records, or concurrent modifications.
In Superset, the tagged_object table is used to associate tags with dashboards, charts, and other objects. It has a unique constraint on the combination of tag_id, object_id, and object_type to prevent duplicates, but if this constraint is violated or if there are unexpected extra rows, deletion can fail with a StaleDataError as you've seen. The deletion logic for dashboards attempts to remove related rows from tagged_object based on object_type and object_id—if more rows exist than expected, this error will occur (source).
To resolve this, check your tagged_object table for duplicate or inconsistent entries related to the dashboard you are trying to delete. You can do this by running a query like:
SELECT * FROM tagged_object WHERE object_id = <dashboard_id> AND object_type = 'dashboard';
If you find duplicate or unexpected rows, you may need to clean them up manually to restore consistency. After cleaning up, try deleting the dashboard again.
No similar issues or recent changes related to this specific error were found in the Superset repository. If this problem recurs, it may indicate a bug in how tags are managed or deleted for dashboards, especially if dashboards are created and deleted in rapid succession or via automation. If you continue to encounter this, consider capturing the exact state of the tagged_object table before deletion and sharing it for further analysis.
To reply, just mention my name @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
Comment From: xavier-GitHub76
The table content :
We can see object_id = 16 for dashboard or chart
I try to delete chart with id = 16
Comment From: xavier-GitHub76
Deleting rows from the tagged_object table allows objects to be deleted.
Comment From: rusackas
Are you doing this via the API or something? I haven't had this issue in the UI at all.
Comment From: hainenber
Based on the LoC address in the stacktrace you gave, I presume the affected version isn't current HEAD in the master branch. In fact, when I try to trace back, it is superseded by this commit.
So I think John did fixed the issue you mentioned once you upgraded to Superset 4.1.0
Comment From: xavier-GitHub76
@rusackas : My actions are done in the UI We use multiple Superset (4.0.2) and the issue is present on several superset
The issue is not always present, I can't find conditions to reproduce it.
@hainenber : Thanks for your comment, we will upgrade to 4.1.0 and try to delete
Comment From: SBIN2010
This bug was fixed here #29229 Judging by the label, the fix was added in version 4.1.0