-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
In job backfill UI, make it clear that backfill policies are not respected #17665
Comments
This is a pretty confusing limitation. Is there a way to prevent a job from triggering if it is a backfill? We want to control how we run backfills for large models, and if someone triggers 4 years worth of partitions for a daily partitioned job without noticing, it's going to be pretty damning :s We can limit concurrency using tags, but is there a way to identify a job was triggered for a backfill and actually prevent it from running? |
Just wanted to say that this very problematic issues has been fixed in this commit. Thank you guys! |
Users have (reasonably) expressed confusion about the fact that asset job backfills don't respect backfill policies.
The root of this is that job partitions are defined in terms of runs: i.e. when you launch a job backfill, you're telling Dagster that you want a run for every partition covered by the backfill. The Partitions Tab on the job page is based around run-based accounting. So supporting backfill policies for asset job backfills would require radical changes to the job partitions data model.
We may be able to eventually make this radical change, but in the mean time, we can still help users avoid a pit of failure. When users try to launch a job backfill for assets that have backfill policies other than the default one, we could do one of:
Related issue: #11962
What we've heard
The text was updated successfully, but these errors were encountered: