v5 - Reports stuck in sending state

[adayush]

Bug description

Hi team,

We have been facing a issue where the Reports are not being completed or failed, they are just stuck in sending state (attached screenshot below).

Observations:

1. Both existing and new reports have this issue
2. We tried using both CSV & PNG & PDF reports sent to Email
3. Worker logs (before setting reports to Error state) just mention that Report Schedule is still working, refusing to re-compute
4. After we set all reports to Error state -> Worker logs have nothing useful. We don't get any logs after the one saying report is triggered (logs shared below). So report is visibly stuck in sending state
5. Reports were working fine 10 days back. Now they are not. We did not restart/rebuild the superset containers then

[2026-05-12 10:05:00,003: INFO/MainProcess] Task reports.scheduler[1daef3b7-ebb2-4f85-991e-245b1991f363] received
[2026-05-12 10:05:00,020: INFO/ForkPoolWorker-1] Scheduling alert New Design BI plans. eta: 2026-05-12 10:05:00
[2026-05-12 10:05:00,026: INFO/MainProcess] Task reports.execute[fea367b7-33f8-4ce9-aeda-c108457ae169] received
[2026-05-12 10:05:00,027: INFO/ForkPoolWorker-2] Executing alert/report, task id: fea367b7-33f8-4ce9-aeda-c108457ae169, scheduled_dttm: 2026-05-12T10:05:00
[2026-05-12 10:05:00,028: INFO/ForkPoolWorker-2] session is validated: id 17, executionid: fea367b7-33f8-4ce9-aeda-c108457ae169
[2026-05-12 10:05:00,052: INFO/ForkPoolWorker-1] Task reports.scheduler[1daef3b7-ebb2-4f85-991e-245b1991f363] succeeded in 0.04761948483064771s: None
[2026-05-12 10:05:00,210: INFO/ForkPoolWorker-2] Running report schedule fea367b7-33f8-4ce9-aeda-c108457ae169 as user sharpsell-admin
[2026-05-12 10:05:00,334: WARNING/ForkPoolWorker-2] A downstream warning occurred while generating a report: fea367b7-33f8-4ce9-aeda-c108457ae169. Report Schedule is still working, refusing to re-compute.
Traceback (most recent call last):
  File "/app/superset/tasks/scheduler.py", line 99, in execute
    ).run()
      ^^^^^
  File "/app/superset/utils/decorators.py", line 266, in wrapped
    return on_error(ex)
           ^^^^^^^^^^^^
  File "/app/superset/utils/decorators.py", line 236, in on_error
    raise ex
  File "/app/superset/utils/decorators.py", line 259, in wrapped
    result = func(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^
  File "/app/superset/commands/report/execute.py", line 896, in run
    ).run()
      ^^^^^
  File "/app/superset/utils/decorators.py", line 266, in wrapped
    return on_error(ex)
           ^^^^^^^^^^^^
  File "/app/superset/utils/decorators.py", line 236, in on_error
    raise ex
  File "/app/superset/utils/decorators.py", line 259, in wrapped
    result = func(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^
  File "/app/superset/commands/report/execute.py", line 858, in run
    ).next()
      ^^^^^^
  File "/app/superset/commands/report/execute.py", line 783, in next
    raise exception_working
superset.commands.report.exceptions.ReportSchedulePreviousWorkingError: Report Schedule is still working, refusing to re-compute.
[2026-05-12 10:05:00,341: INFO/ForkPoolWorker-2] Task reports.execute[fea367b7-33f8-4ce9-aeda-c108457ae169] succeeded in 0.31424060883000493s: None

Here's what we've tried so far, but didn't help:

1. Marking all reports being in "Working" state to "Error" state using SQL query
2. Also tried marking them to "Not triggered"
3. Rebuilt superset image and restarted worker
4. Increased celery worker timeout in config from 1 minute to 5 minutes

Screenshots/recordings

Superset version

5.0.0

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.

[dosubot]

Hey @adayush, this is a known pattern in Superset's report state machine. Here's what's happening and some things to try:

Why reports get stuck: When a report starts executing, it enters WORKING state. If the underlying process (screenshot capture, CSV generation, etc.) fails silently — e.g., due to a Celery worker crash, Selenium/browser failure, or database connectivity hiccup — the state never transitions to SUCCESS or ERROR. All subsequent runs then hit the ReportSchedulePreviousWorkingError because the system thinks the previous execution is still in progress [1].

The timeout mechanism: Superset has a built-in timeout (ALERT_REPORTS_DEFAULT_WORKING_TIMEOUT, default 3600 seconds / 1 hour) that should eventually force stuck reports into ERROR state [2]. If your reports have been stuck longer than that, the timeout mechanism itself may not be functioning — possibly because ALERT_REPORTS_WORKING_TIME_OUT_KILL is disabled or the Celery beat scheduler isn't triggering re-checks.

Things to try:

1. Ensure these config values are set:

   ALERT_REPORTS_WORKING_TIME_OUT_KILL = True  # default is True
   ALERT_REPORTS_DEFAULT_WORKING_TIMEOUT = 3600  # seconds

   [3]

2. Reset the execution log, not just the report state. When you manually set report last_state to ERROR, you also need to ensure the report execution log (report_execution_log table) reflects a terminal state. The system checks for the last log entry with state = 'working' and error_message IS NULL to determine if a report is still running [4]. Try updating those log entries too:

   UPDATE report_execution_log 
   SET state = 'error', error_message = 'Manually reset' 
   WHERE state = 'working' AND error_message IS NULL;

3. Check your screenshot/browser infrastructure. The fact that you see no logs after "Running report schedule..." suggests the process is hanging during content generation (screenshot or data fetch). If you're using Selenium, verify ChromeDriver and Chrome versions match. Consider switching to Playwright which is more stable in Superset 5.0:

   FEATURE_FLAGS = {
       "PLAYWRIGHT_REPORTS_AND_THUMBNAILS": True,
   }

   [5]

4. Check Celery worker concurrency and timeouts. You mentioned increasing timeout to 5 minutes — but the report itself may be hanging indefinitely on a subprocess (e.g., Selenium). Ensure Celery's --task-time-limit (hard kill) is set to something reasonable like ALERT_REPORTS_DEFAULT_WORKING_TIMEOUT + 10 so workers forcibly kill hung tasks [6].

The key insight is that setting last_state on the report schedule alone isn't sufficient — the execution log entries are what the state machine actually checks to decide if a report is "still working."

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[adayush]

@dosu

1. Config values are set already in config.py file
2. We had already tried setting the report_execution_log rows' state to error. It did not help
3. We are using silenium and it has been working fine till 10 days back. And it is working fine in other deployments we have with the exact same image
4. I don't think this is a celery worker timeout issue and I'm getting no logs at all

[adayush]

@sfirke please check this, would be great if you can help

[dosubot]

Thanks for the additional context. Given that:

• Config is correct
• Execution log reset didn't help
• Same image works in other deployments
• No logs appear after "Running report schedule..."

The fact that you get zero logs after that point is a strong signal. Here's what happens in the code right after that log line: the system enters a state machine which calls into the screenshot/data generation layer [1]. The screenshot layer has several known silent failure modes where exceptions are caught but not propagated or logged — the function just returns None and the caller doesn't know it failed [2] [3].

Here are the most likely culprits for your specific scenario (same image, worked before, now silently stuck):

1. Report execution user issue — If the user configured as the report executor was deactivated, had a password change, or lost permissions, the WebDriver will load a login page instead of the dashboard/chart. It then waits for chart elements that never appear and hangs until timeout — with no useful log output [4]. This is the #1 silent failure mode. Verify this user is active and can log in.

2. Selenium/ChromeDriver process hanging — If ChromeDriver is crashing or hanging on startup (e.g., shared memory issues in Docker, /dev/shm too small), the process blocks with no output. Check:

• Is /dev/shm adequately sized? (Common Docker issue — add --shm-size=2g or mount tmpfs)
• Can you exec into the worker container and manually run chromedriver --version?

3. Network connectivity from the worker — Since this is the same image working elsewhere, check if the Celery worker can actually reach Superset's web UI internally. The WebDriver navigates to WEBDRIVER_BASEURL to capture screenshots. If DNS resolution or network policies changed in this specific deployment ~10 days ago, the page load would hang silently.

Debugging steps I'd recommend:

1. Check the report executor user — log in manually with that user's credentials

2. Enable DEBUG logging for superset.utils.screenshots — add to your config:

   ADDITIONAL_MODULE_DS_MAP = {
       "superset.utils.screenshots": logging.DEBUG,
   }

3. Test WebDriver connectivity — exec into the worker pod and try:

   from selenium import webdriver
   # attempt to create a browser session and navigate to WEBDRIVER_BASEURL

4. Check /dev/shm in the worker container — df -h /dev/shm

The fact that it broke ~10 days ago without an image change strongly suggests an infrastructure or user/permissions change in that specific environment rather than a code issue.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[adayush]

1. I confirmed there is no password change that happened
2. I want to know if there's anything I can do before I enable debugging (its a production environment, I can't make changes that easily)
3. I have tried selenium via exec, it worked fine
4. will check but it is unlikely that this is a issue

[venkatamandavilli-code]

Thanks for reporting this issue and sharing the logs in detail. The behavior seems consistent with the report execution state not being cleared correctly after an earlier task attempt.

Based on the stack trace, it looks like Superset still considers the report execution as active (Report Schedule is still working) even after the worker process completes. In some cases, this can happen if the task state, Celery metadata, or report execution status becomes out of sync after a failed or interrupted run.

It may help to verify:

• whether stale task entries still exist in the Celery backend or metadata database
• whether multiple scheduler/worker instances are picking up the same report simultaneously
• whether report execution cleanup is completing correctly after exceptions
• whether there were any environment or dependency updates during the last 10 days, even without container rebuilds

The issue also feels somewhat similar to earlier report execution/state synchronization problems seen around Superset v5 alert/report workflows.

Thanks again for documenting the logs and troubleshooting steps clearly.