New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send pulse triggers should respect report timezone #42502
Send pulse triggers should respect report timezone #42502
Conversation
|
@@ -265,7 +265,7 @@ | |||
:priority (.getPriority trigger) | |||
:start-time (.getStartTime trigger) | |||
:may-fire-again? (.mayFireAgain trigger) | |||
:data (.getJobDataMap trigger)}) | |||
:data (into {} (.getJobDataMap trigger))}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you need to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need this in tests because we can't compare JobDataMap with clojure map
@@ -75,6 +87,7 @@ | |||
(triggers/with-schedule | |||
(cron/schedule | |||
(cron/cron-schedule (u.cron/schedule-map->cron-string schedule-map)) | |||
(cron/in-time-zone (TimeZone/getTimeZone ^String timezone)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the fix
Why should updating the report time zone change the trigger of every pulse? For example, if I schedule an alert at midnight when the report time zone is time zone A, then I change the report time zone to time zone B, I would still expect the alert to fire at midnight in time zone A. Maybe that's how it worked previously, but that seems very surprising. |
(defn- send-trigger-timezone | ||
[] | ||
(or (driver/report-timezone) | ||
(qp.timezone/system-timezone-id) | ||
"UTC")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like it could be DRY'd up with other parts of the codebase outside of pulses. It doesn't feel right to have a notion of the trigger time zone specific to send pulses task.
Also, before we were just using (driver/report-timezone)
without (qp.timezone/system-timezone-id)
, can you explain the change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's the fallback timezone id we used in QP so I think we should apply it for pulse too:
(if use-report-timezone-id-if-unsupported? |
It's also used in other tasks like persist refresh : https://github.com/metabase/metabase/blob/send-pulse-trigger-respect-timezone/src/metabase/task/persist_refresh.clj#L286
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I'm suggesting to DRY this up then. Otherwise they can get out of sync. Instead of duplicating this logic again, update-send-pulse-triggers-timezone!
, and the cron-schedule
function should use the same function that contains the logic for getting the reporting time zone ID. Why not use results-timezone-id
from the QP code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
results-timezone-id
requires a DB. In case of pulse a dashboard can contain questions from more than 1 DB.
Wdyt if we move this to metabase.task
or a new metabase.task.util
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind where it goes too much. But I'm seeing a couple more places this could be DRYed up too:
metabase/src/metabase/email/messages.clj
Lines 577 to 579 in e6f4795
(defn- schedule-timezone | |
[] | |
(or (driver/report-timezone) "UTC")) |
metabase/src/metabase/task/index_values.clj
Lines 82 to 84 in e6f4795
(cron/in-time-zone (TimeZone/getTimeZone (or (driver/report-timezone) | |
(qp.timezone/system-timezone-id) | |
"UTC"))) |
answered in https://metaboat.slack.com/archives/C0641E4PB9B/p1715349254844079 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but will let Cal have final say
(classloader/require 'metabase.task.send-pulses) | ||
((resolve 'metabase.task.send-pulses/update-send-pulse-triggers-timezone!))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll be nice to replace this sneak hidden cross-module dependency with an event system - maybe in scope for the notifications refactor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it's one of my annoyance as well!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me as long as the duplication of logic around the reporting time zone is resolved. That could be left to another PR though, because it looks like an existing issue
We use the cron job to send pulse triggers, but we need to ensure it's triggered in the
report-timezone
; this PR ensures we do that and also makes changing the report-timezone update all trigger's timezone.Reported in: https://metaboat.slack.com/archives/CKZEMT1MJ/p1715331817582219