Duplicate Report/Alert Execution Logs with Same UUID in Superset 4.1.2: One with 'working', One with 'success' #35658
Replies: 1 comment
-
|
This behavior is caused by the state machine logic in Superset: each state transition (like 'working' and then 'success') creates a new execution log entry with the same UUID, scheduled time, and start time, but a different state. There’s no deduplication or update logic—each transition inserts a new row, which can result in duplicate entries if the state machine runs more than once for the same execution. This is not documented as a known issue, and there’s no fix or workaround in 4.1.2. You could potentially mitigate this by adding a uniqueness constraint on the execution UUID or updating the log creation logic to upsert rather than always insert new rows. For more details, see the relevant code in the report execution command and state classes (source). To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
In Superset 4.1.2, when a Report or Alert is executed for the first time after creation, two execution log entries are generated with the same UUID (Execution ID).
For example:
Execution ID | Scheduled at (UTC) | Start at (UTC) | Duration | State
696d3e | 2025-10-14 18:52:00 | 2025-10-15 02:52:00 | 00:00:00.000 | success
696d3e | 2025-10-14 18:52:00 | 2025-10-15 02:52:00 | 00:00:00.000 | working
As shown, both records have:
The same Execution ID (696d3e)
Identical scheduled and start timestamps
No duration
One in success state, one in working state
However, only one successful execution log is expected, as this duplication causes confusion and affects downstream log processing.
This issue occurs consistently during the first execution of a newly created or updated Report/Alert. Subsequent executions may not show this behavior, or appear less frequently.
Environment:
Superset version: 4.1.2
Python version: 3.10
OS: Ubuntu
Deployment: Standalone (Celery + Gunicorn)
Could this be related to a race condition in task scheduling or state update logic? Is there a known fix or workaround?
Thanks!
@dosu
Beta Was this translation helpful? Give feedback.
All reactions