gabotorresruiz commented on code in PR #43307:
URL: https://github.com/apache/superset/pull/43307#discussion_r3825196495
##########
superset/tasks/cron_util.py:
##########
@@ -19,12 +19,57 @@
from collections.abc import Iterator
from datetime import datetime, timedelta
+from cron_descriptor import ExpressionDescriptor, get_description
from croniter import croniter, CroniterBadDateError
from flask import current_app
from pytz import timezone as pytz_timezone, UnknownTimeZoneError
logger = logging.getLogger(__name__)
+# Field values that place no restriction on a cron field. ``?`` is the Quartz
+# spelling of "no specific value" and is accepted by ``cron_descriptor``.
+UNRESTRICTED_CRON_FIELDS = {"*", "?"}
+
+
+def get_cron_description(cron: str) -> str:
+ """
+ Build a human readable description of a cron expression.
+
+ ``cron_descriptor`` renders a restricted day-of-month next to a restricted
+ day-of-week as a single comma separated clause -- ``0 9 7-11 * 2`` becomes
+ "At 09:00 AM, on day 7 through 11 of the month, only on Tuesday" -- which
+ reads as an intersection. POSIX cron, and therefore ``croniter`` (which
+ picks the fire times in :func:`cron_schedule_window`), takes the *union* of
+ the two fields when both are restricted: the schedule fires on every
+ matching day of the month as well as on every matching day of the week.
+ Join the two clauses with "or" so the description matches when the job
+ really runs.
+ """
+ description = get_description(cron)
+
+ fields = cron.split()
+ if len(fields) != 5:
+ return description
Review Comment:
Not a blocker, and mostly a correction to this thread: the 6-field case
doesn't fall through to a misleading description. `croniter.is_valid` accepts
seconds-last 6-field expressions like `0 9 1,15 * 1-5 30`, but
`get_description` parses 6 fields as Quartz seconds-first and raises
`FormatException` on them, before the `len(fields) != 5` check is ever reached.
That behavior is identical on master, so this PR neither fixes nor worsens it,
and widening the length check as suggested wouldn't help since the two
libraries genuinely disagree on where the seconds field sits. If we want to
harden this later, catching `FormatException` in `get_cron_description` and
falling back to the raw crontab string would close the pre-existing failure for
validator-accepted 6-field schedules; that's a separate follow-up.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
