You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "adayush (via GitHub)" <gi...@apache.org> on 2026/02/24 11:38:00 UTC
[I] v5 - Reports not working [superset]
adayush opened a new issue, #38216:
URL: https://github.com/apache/superset/issues/38216
### Bug description
## Observation
- I created a report with email notification and a schedule
- Report doesn't get sent on the scheduled time (4pm)
- I don't see any entry in Report log or in `report_execution_log` table
- Some other reports worked fine in the morning at around 9am. But this one doesn't get triggered
## What I've tried so far but didn't help
- I recreated beat container
- I confirmed timezones
- I confirmed this report is configured the same way as other reports
### Screenshots/recordings
_No response_
### Superset version
5.0.0
### Python version
3.9
### Node version
16
### Browser
Firefox
### 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] v5 - Reports not working [superset]
Posted by "adayush (via GitHub)" <gi...@apache.org>.
adayush commented on issue #38216:
URL: https://github.com/apache/superset/issues/38216#issuecomment-3958117060
For the checks 1, 2, 3 that you mentioned:
If it was a config issue, I think all reports would have faced the same problem. But some reports are getting triggered fine while some are not getting triggered
I'll give you examples:
### Report 1
1. Schedule is reflected in DB, timezone is correct
2. beat logs show report.schedule (i would see it even if there are no reports scheduled, this is my understanding)
3. At the time of schedule, celery logs show `Executing alert/report` and I get the report emailed
### Report 2
1. Schedule is reflected in DB, timezone is correct
2. beat logs show report.schedule (i would see it even if there are no reports scheduled, this is my understanding)
3. At the time of schedule, there are no celery logs
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] v5.0.0 - some reports run properly, others fail to fire [superset]
Posted by "rusackas (via GitHub)" <gi...@apache.org>.
rusackas closed issue #38216: v5.0.0 - some reports run properly, others fail to fire
URL: https://github.com/apache/superset/issues/38216
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] v5.0.0 - some reports run properly, others fail to fire [superset]
Posted by "sfirke (via GitHub)" <gi...@apache.org>.
sfirke commented on issue #38216:
URL: https://github.com/apache/superset/issues/38216#issuecomment-3985949581
In that case, does any new report that you create work at all?
- If yes, some new reports work, but re-creating that working report from scratch does not work, then that's a clue in terms of what the differences are between working and not
- If no, no newly-created reports work, that would point elsewhere. Maybe something has gotten corrupted?
(Right now there's little that the project can do to debug this, given that so far there's no way to reproduce it and no one else has reported it.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] v5.0.0 - some reports run properly, others fail to fire [superset]
Posted by "rusackas (via GitHub)" <gi...@apache.org>.
rusackas commented on issue #38216:
URL: https://github.com/apache/superset/issues/38216#issuecomment-4898962217
This deployment-specific 5.0.0 celery-beat scheduling anomaly seeems to be affecting only a couple of the reporter's environments, and sfirke exhausted debugging with no repro and stated the project can't act without one. Closing as not-reproducible.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] v5 - Reports not working [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
dosubot[bot] commented on issue #38216:
URL: https://github.com/apache/superset/issues/38216#issuecomment-3951148647
<!-- Greeting -->
Hi @adayush! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the superset team.
<!-- Answer -->
The most common cause of scheduled reports not triggering with no log entries in Docker deployments is **configuration file placement**. In Docker Compose environments, [Superset only loads custom configuration from `docker/pythonpath_dev/superset_config_docker.py`](https://github.com/apache/superset/issues/37357) — if your config is elsewhere, all custom settings including `ALERT_REPORTS`, Celery configuration, and SMTP settings are ignored.
**Quick checks:**
1. **Verify your config is being loaded** — check container logs for:
```
Loaded your Docker configuration at [docker/pythonpath_dev/superset_config_docker.py]
```
If you see "Loaded your LOCAL configuration" instead, that's the problem.
2. **Check Celery beat/worker logs** for `reports.scheduler` tasks. If these don't appear, the scheduler isn't running at all.
3. **Verify feature flags aren't being overridden** by environment variables:
```bash
docker exec <container> python -c "from superset import app; print(app.config['ALERT_REPORTS'])"
docker exec <container> python -c "from superset import app; print(app.config['ALERT_REPORTS_NOTIFICATION_DRY_RUN'])"
```
4. **Try "Run Now"** on the report from the UI — if that works, the issue is scheduling rather than execution.
5. **Check if the report is stuck in WORKING state** from a previous run. [Reports can get stuck](https://github.com/apache/superset/discussions/34121) if Celery workers became unhealthy. Restarting workers can clear this.
Since your 9am reports worked, also verify:
- The 4pm report is still marked as `active` in the database
- The crontab expression is correct
- [Timezone settings are consistent](https://github.com/apache/superset/issues/26962) — try setting `TZ=UTC` in your Docker environment and keeping your report timezone as UTC
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/8b00314e-8fd5-45f7-9107-1b95a8b26779?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/8b00314e-8fd5-45f7-9107-1b95a8b26779?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/8b00314e-8fd5-45f7-9107-1b95a8b26779?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/8b00314e-8fd5-45f7-9107-1b95a8b26779?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/8b00314e-8fd5-45f7-9107-1b95a8b26779?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/8b00314e-8fd5-45f7-9107-1b95a8b26779?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/8b00314e-8fd5-45f7-9107-1b95a8b26779?feedback_type=other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=The%20most%20common%20cause%20of%20scheduled%20reports%20not%20triggering%20with%20no%20log%20entries%20in%20Docker%20deployments%20is%20%2A%2Aconfiguration%20file%20placement%2A%2A.%20In%20Docker%20Compose%20environments%2C%20%5BSuperset%20only%20loads%20custom%20configuration%20from%20%60docker/pythonpath_dev/superset_config_docker.py%60%5D%28https%3A//github.com/apache/superset/issues/37357%29%20%E2%80%94%20if%20your%20config%20is%20elsewhere%2C%20all%20custom%20settings%20including%20%60ALERT_REPORTS%60%2C%20Celery%20configuration%2C%20and%20SMTP%20settings%20are%20ignored.%0A%0A%2A%2AQuick%20checks%3A%2A%2A%0A%0A1.%20%2A%2AVerify%20your%20config%20is%20being%20loaded%2A%2A%20%E2%80%94%20check%20container%20logs%20for%3A%0A%20%20%20%60%60%60%0A
%20%20%20Loaded%20your%20Docker%20configuration%20at%20%5Bdocker/pythonpath_dev/superset_config_docker.py%5D%0A%20%20%20%60%60%60%0A%20%20%20If%20you%20see%20%22Loaded%20your%20LOCAL%20configuration%22%20instead%2C%20that%27s%20the%20problem.%0A%0A2.%20%2A%2ACheck%20Celery%20beat/worker%20logs%2A%2A%20for%20%60reports.scheduler%60%20tasks.%20If%20these%20don%27t%20appear%2C%20the%20scheduler%20isn%27t%20running%20at%20all.%0A%0A3.%20%2A%2AVerify%20feature%20flags%20aren%27t%20being%20overridden%2A%2A%20by%20environment%20variables%3A%0A%20%20%20%60%60%60bash%0A%20%20%20docker%20exec%20%3Ccontainer%3E%20python%20-c%20%22from%20superset%20import%20app%3B%20print%28app.config%5B%27ALERT_REPORTS%27%5D%29%22%0A%20%20%20docker%20exec%20%3Ccontainer%3E%20python%20-c%20%22from%20superset%20import%20app%3B%20print%28app.config%5B%27ALERT_REPORTS_NOTIFICATION_DRY_RUN%27%5D%29%22%0A%20%20%20%60%60%60%0A%0A4.%20%2A%2ATry%20%22Run%20Now%22%2A%2A%20on%20the%20report%20from%20the%20UI%20%E2%80%94%
20if%20that%20works%2C%20the%20issue%20is%20scheduling%20rather%20than%20execution.%0A%0A5.%20%2A%2ACheck%20if%20the%20report%20is%20stuck%20in%20WORKING%20state%2A%2A%20from%20a%20previous%20run.%20%5BReports%20can%20get%20stuck%5D%28https%3A//github.com/apache/superset/discussions/34121%29%20if%20Celery%20workers%20became%20unhealthy.%20Restarting%20workers%20can%20clear%20this.%0A%0ASince%20your%209am%20reports%20worked%2C%20also%20verify%3A%0A-%20The%204pm%20report%20is%20still%20marked%20as%20%60active%60%20in%20the%20database%0A-%20The%20crontab%20expression%20is%20correct%0A-%20%5BTimezone%20settings%20are%20consistent%5D%28https%3A//github.com/apache/superset/issues/26962%29%20%E2%80%94%20try%20setting%20%60TZ%3DUTC%60%20in%20your%20Docker%20environment%20and%20keeping%20your%20report%20timezone%20as%20UTC) [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/issues/38216)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] v5 - Reports not working [superset]
Posted by "adayush (via GitHub)" <gi...@apache.org>.
adayush commented on issue #38216:
URL: https://github.com/apache/superset/issues/38216#issuecomment-3958225256
This is all I've tried:
### What we observed
* One report schedule **never triggers** (no Celery logs, no email, no UI log).
* Another report in the **same environment works reliably**.
* Celery Beat and workers are up and healthy.
---
### Environment
* **Apache Superset v5**
* Celery + Redis
* Celery Beat running in a **separate container**
* Reports scheduled with timezone `Asia/Calcutta`
---
### What we tried (chronological)
1. **Verified Celery Beat health**
* Beat logs show `Scheduler: Sending due task reports.scheduler` every minute.
* Confirmed this is expected behavior (global scheduler tick).
2. **Found and fixed Celery Beat PID issue**
* Beat was failing due to stale `/tmp/celerybeat.pid`.
* Fixed by restarting container (`docker compose down beat && up -d`).
* After this, Beat logs and scheduler task execution resumed normally.
3. **Confirmed scheduler task execution**
* Worker logs show:
* `reports.scheduler received`
* `reports.scheduler succeeded`
* For the broken report, **no `reports.execute` task is ever enqueued**.
4. **Compared working vs non-working reports**
* Working report:
* Has `last_eval_dttm` populated
* `last_state = Success`
* Generates `report_schedule_log` entries
* Broken report:
* `last_eval_dttm = NULL`
* `last_state = Not triggered` (initially)
* No rows ever appear in `report_schedule_log`
5. **Reset execution state of the broken report**
* Manually set:
* `last_state = NULL`
* `last_eval_dttm = NULL`
* `last_value = NULL`
* `last_value_row_json = NULL`
* Result: **no change**, still no Celery execution.
6. **Changed cron schedules**
* Updated cron times via UI (e.g. 3:25 → 4:59).
* Also tested future times and minute-level schedules.
* Result: **still no Celery logs** for this report.
7. **Verified time & timezone**
* Confirmed `date` is identical in:
* Superset web container
* Celery worker
* Celery beat
* Timezone (`Asia/Calcutta`) has been working historically.
8. **Validated dashboard / chart**
* Confirmed the chart and dashboard exist.
* Re-selected the **same dashboard as the working report**.
* Saved and retried scheduling.
* Result: **still skipped silently**.
9. **Verified recipients**
* Confirmed email recipients exist for the broken report.
* Compared recipient tables with the working report — no issue found.
10. **Observed final DB state (broken report)**
* `active = true`
* `crontab` correct
* `timezone = Asia/Calcutta`
* `dashboard_id` valid
* `last_eval_dttm = NULL`
* `last_state = NULL`
* No entries in `report_schedule_log`
* No `reports.execute` task ever logged by Celery
---
### Key symptom to highlight
* `reports.scheduler` **runs successfully**
* Other reports in the same system work.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] v5 - Reports not working [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
dosubot[bot] commented on issue #38216:
URL: https://github.com/apache/superset/issues/38216#issuecomment-3958157385
<!-- Answer -->
Thanks for the detailed comparison — this narrows it down significantly. Since beat is running and Report 1 executes fine, the issue is likely in how Report 2's schedule is being evaluated by the [cron window matching logic](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/tasks/scheduler.py#L60-L78).
The scheduler uses a time window (controlled by `ALERT_REPORTS_CRON_WINDOW_SIZE`, default 59 seconds) to determine which reports should run. [If a report's crontab doesn't produce an execution time within that window, it's silently skipped with no log output](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/tasks/cron_util.py#L30-L51).
**Things to check for Report 2:**
1. **Compare crontab expressions** — Are they identical? Even subtle differences (like `0 16 * * *` vs `* 16 * * *`) affect window matching differently
2. **Check `last_state`** in the database:
```sql
SELECT last_state, last_eval_dttm FROM report_schedule WHERE name = '<Report2>';
```
If it's stuck in `Working`, the report won't be re-queued
3. **Verify timezone** — Both reports should have the same timezone string. The scheduler [converts times to the report's timezone](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/tasks/cron_util.py#L42) for cron evaluation
4. **Test "Run Now"** on Report 2 from the UI — if it works, the issue is purely scheduling/timing related
Can you share the crontab expressions and timezone settings for both reports?
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/f2c24330-c1aa-4436-b666-1872e488fd84?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/f2c24330-c1aa-4436-b666-1872e488fd84?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/f2c24330-c1aa-4436-b666-1872e488fd84?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/f2c24330-c1aa-4436-b666-1872e488fd84?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f2c24330-c1aa-4436-b666-1872e488fd84?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/f2c24330-c1aa-4436-b666-1872e488fd84?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/f2c24330-c1aa-4436-b666-1872e488fd84?feedback_type=other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=Thanks%20for%20the%20detailed%20comparison%20%E2%80%94%20this%20narrows%20it%20down%20significantly.%20Since%20beat%20is%20running%20and%20Report%201%20executes%20fine%2C%20the%20issue%20is%20likely%20in%20how%20Report%202%27s%20schedule%20is%20being%20evaluated%20by%20the%20%5Bcron%20window%20matching%20logic%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/tasks/scheduler.py%23L60-L78%29.%0A%0AThe%20scheduler%20uses%20a%20time%20window%20%28controlled%20by%20%60ALERT_REPORTS_CRON_WINDOW_SIZE%60%2C%20default%2059%20seconds%29%20to%20determine%20which%20reports%20should%20run.%20%5BIf%20a%20report%27s%20crontab%20doesn%27t%20produce%20an%20execution%20time%20within%20that%20window%2C%20it%27s%20silent
ly%20skipped%20with%20no%20log%20output%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/tasks/cron_util.py%23L30-L51%29.%0A%0A%2A%2AThings%20to%20check%20for%20Report%202%3A%2A%2A%0A%0A1.%20%2A%2ACompare%20crontab%20expressions%2A%2A%20%E2%80%94%20Are%20they%20identical%3F%20Even%20subtle%20differences%20%28like%20%600%2016%20%2A%20%2A%20%2A%60%20vs%20%60%2A%2016%20%2A%20%2A%20%2A%60%29%20affect%20window%20matching%20differently%0A%0A2.%20%2A%2ACheck%20%60last_state%60%2A%2A%20in%20the%20database%3A%0A%20%20%20%60%60%60sql%0A%20%20%20SELECT%20last_state%2C%20last_eval_dttm%20FROM%20report_schedule%20WHERE%20name%20%3D%20%27%3CReport2%3E%27%3B%0A%20%20%20%60%60%60%0A%20%20%20If%20it%27s%20stuck%20in%20%60Working%60%2C%20the%20report%20won%27t%20be%20re-queued%0A%0A3.%20%2A%2AVerify%20timezone%2A%2A%20%E2%80%94%20Both%20reports%20should%20have%20the%20same%20timezone%20string.%20The%20scheduler%20%5Bconverts%20times%20to%20the%20report%
27s%20timezone%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/tasks/cron_util.py%23L42%29%20for%20cron%20evaluation%0A%0A4.%20%2A%2ATest%20%22Run%20Now%22%2A%2A%20on%20Report%202%20from%20the%20UI%20%E2%80%94%20if%20it%20works%2C%20the%20issue%20is%20purely%20scheduling/timing%20related%0A%0ACan%20you%20share%20the%20crontab%20expressions%20and%20timezone%20settings%20for%20both%20reports%3F) [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/issues/38216)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org