apache/superset · warning · ReportScheduleUnexpectedError
Report schedule was modified or deleted by another process d
Error message
Report schedule was modified or deleted by another process during execution
What it means
ReportScheduleUnexpectedError wrapping a SQLAlchemy StaleDataError: while the execution was finishing, the UPDATE that persists the final log state failed because the report_schedule row's version changed or was deleted by another transaction. The code rolls back, logs a warning explaining the report was likely deleted mid-run, and re-raises as this error so the worker marks the execution failed cleanly.
Source
Thrown at superset/commands/report/execute.py:468
uuid=self._execution_id,
)
db.session.add(log)
log.end_dttm = datetime.now(timezone.utc).replace(tzinfo=None)
log.value = self._report_schedule.last_value
log.value_row_json = self._report_schedule.last_value_row_json
log.state = effective_state
log.error_message = log_message
db.session.commit() # pylint: disable=consider-using-transaction
except StaleDataError as ex:
# Report schedule was modified or deleted by another process
db.session.rollback() # pylint: disable=consider-using-transaction
logger.warning(
"Report schedule (execution %s) was modified or deleted "
"during execution. This can occur when a report is deleted "
"while running.",
self._execution_id,
)
raise ReportScheduleUnexpectedError(
"Report schedule was modified or deleted by another process "
"during execution"
) from ex
def _get_url(
self,
user_friendly: bool = False,
result_format: Optional[ChartDataResultFormat] = None,
**kwargs: Any,
) -> str:
"""
Get the url for this report schedule: chart or dashboard
"""
chart = self._report_schedule.chart
dashboard = self._report_schedule.dashboard
# Soft delete removed the FK-level guarantee that a report's target
# chart exists: ``chart`` is a visibility-filtered relationship, so aView on GitHub (pinned to f4587218dd)
Solutions
- No data fix needed — the report was intentionally changed/deleted; verify the schedule still exists and let the next fire run normally
- Prevent overlap by spacing crontabs (and see ALERT_REPORTS_MINIMAL_INTERVAL) so executions don't race on the same row
- If it recurs without manual deletes, audit for duplicate Celery beat schedules firing the same task twice
Defensive patterns
Strategy: try-catch
Try / catch
try:
_set_log_state()
except ReportScheduleUnexpectedError as ex:
if 'modified or deleted' in str(ex):
logger.warning('report changed mid-run; safe to ignore')
return # not a data-loss situation
raise Prevention
- Space schedule fires so executions of one report never overlap
- Prefer editing reports between fires, not during; check the worker's active runs first
- Ensure only one Celery beat scheduler instance is running to avoid duplicate fires
When it happens
Trigger: A user deletes or edits the report schedule (or its owner/relations) while a Celery execution of that schedule is in flight; two overlapping executions race on the same row.
Common situations: Deleting a misbehaving report right as its scheduled run starts; overlapping schedules after worker restarts; long screenshot runs spanning an admin's cleanup of old reports.
Related errors
- A timeout occurred while taking a screenshot.
- A timeout occurred while generating a dataframe.
- validation_error
- security_error
- There are associated alerts or reports: %(report_names)s
AI-assisted analysis of apache/superset@f4587218dd (2026-08-14).
Data as JSON: /api/errors/e9637e65d3c9137e.
Report an issue: GitHub.