You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DATE_FORMAT_IN_EMAIL_SUBJECT only evaluated at schedule save time #35908
I am using the DATE_FORMAT_IN_EMAIL_SUBJECT feature with an hourly scheduled report using a token to display the current datetime i.e. Propane Hourly Report %c. The substitution works the title of the email sent is "[Report] Propane Hourly Report Wed Oct 29 09:32:01 2025". However the datetime substitution is for the datetime the schedule was saved and never changes for each new email sent.
Should the substitution not be evaluated with each new hourly email sent ?
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.
The datetime substitution in the email subject for scheduled reports should be evaluated at each email send, not just when the schedule is saved. The current behavior you’re seeing—where all emails have the same datetime value—is a bug in the implementation. Superset sets the datetime once when the notification class is loaded, so every email uses that static value instead of the actual send time. The documentation and tests both expect dynamic evaluation per send, matching your expectation. You can see the technical details in the code here and the documented intent here.
To fix this, the code should use the current datetime at send time, not a class-level value. There isn’t a workaround or patch in recent pull requests or discussions yet. If you need to address this immediately, you’d need to update the notification logic so the datetime is generated fresh for each email send.
Good news, this was already fixed in #40693 - the timestamp was a class-level value evaluated once at import time, so it'd freeze for the life of the worker. That PR moved it into __init__ so it's stamped per-send, and added regression coverage for it. Should be in the next release. Closing as resolved, but ping me if you still see it on a current build.
Activity
dosubot commentedon Oct 30, 2025
Hi @globaljonsey! I'm Dosu and I’m helping the superset team.
The datetime substitution in the email subject for scheduled reports should be evaluated at each email send, not just when the schedule is saved. The current behavior you’re seeing—where all emails have the same datetime value—is a bug in the implementation. Superset sets the datetime once when the notification class is loaded, so every email uses that static value instead of the actual send time. The documentation and tests both expect dynamic evaluation per send, matching your expectation. You can see the technical details in the code here and the documented intent here.
To fix this, the code should use the current datetime at send time, not a class-level value. There isn’t a workaround or patch in recent pull requests or discussions yet. If you need to address this immediately, you’d need to update the notification logic so the datetime is generated fresh for each email send.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

sadpandajoe commentedon Nov 3, 2025
@US579 Do you remember if this would check on each send?
sadpandajoe commentedon Nov 3, 2025
PR that introduced the feature: #31413
rusackas commentedon Nov 18, 2025
CC @yousoph in case there are more folks to call in on alerts/reports issues.
rusackas commentedon Jun 17, 2026
Good news, this was already fixed in #40693 - the timestamp was a class-level value evaluated once at import time, so it'd freeze for the life of the worker. That PR moved it into
__init__so it's stamped per-send, and added regression coverage for it. Should be in the next release. Closing as resolved, but ping me if you still see it on a current build.