Skip to content
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

Fix custom tz/cron schedule ignored in build_schedule_from_partitioned_job #22015

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

clairelin135
Copy link
Contributor

@clairelin135 clairelin135 commented May 21, 2024

Previously, logic in build_schedule_from_partitioned_job that infers partitions defs from the assets when a partitions def is not defined on the job would ignore any custom tz/cron schedule provided. This PR fixes.

A different code path in the same function that evaluates jobs with a partitions def would raise an error when providing a custom tz/cron schedule. This PR adjusts this code path to accept these params for parity.

@clairelin135
Copy link
Contributor Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @clairelin135 and the rest of your teammates on Graphite Graphite

@clairelin135 clairelin135 changed the title Fix tz/cron schedule being ignored in build_schedule_from_partitioned_job Fix custom tz/cron schedule ignored in build_schedule_from_partitioned_job May 21, 2024
@clairelin135 clairelin135 marked this pull request as ready for review May 21, 2024 23:14
@clairelin135 clairelin135 force-pushed the 05-21-claire/fix-tz-being-ignored-in-schedule branch from 1ba3140 to b0a4d04 Compare May 21, 2024 23:23
@clairelin135 clairelin135 requested a review from sryza May 21, 2024 23:48
Copy link
Contributor

@sryza sryza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I've been slow to get to this because I've been waffling on whether it makes sense to allow overriding these properties for time-partitioned assets.

My line of reasoning has been: the main point of this function is to infer these properties from the partitioning on the assets, so that they don't need to be specified redundantly by the user. In the situations where someone would want to set these properties, should they just be using @schedule directly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants