How to customize based on backfill status in declarative automation conditions

[CSRessel]

Throughout our usage so far the automation conditions have proven well designed, and the declarative automation as a whole has decreased cognitive load for us while increasing customizability (a very tough combo to achieve at the same time!). The only area where we are consistently still finding it difficult to automate the policies that we conceive, is the interaction with backfills. There is some customization that interacts with backfills, via in_progress and *_requested operands.

Question

Is it currently possible to check if the particular triggering partition run being evaluated is part of a backfill or not? Or is it possible this could be supported as an automation condition operand, like AutomationCondition.is_backfilling? Finally, other operands are partition specific, but this seems to be both partition and run specific as there could also be a non-backfill run in progress for the partition in question; is it feasible to have an operand like this?

Motivation

For some assets we work with, it would be very helpful to remove the latest time window restrictions and the have data be picked up by the eager automation more aggressively. This would be possible within our throughoutput, except for the interaction between automation and backfills. That interaction can cause massive automation queueing while some of our backfills are running. However, since backfills are a manual intervention for us, we are okay with making the backfill flowthrough of data be a manual followup for now. Being able to customize an automation condition to include something like & ~AutomationCondition.is_backfilling would solve the issue entirely, in a manner preferable to the latest time window check.

[schrockn]

@OwenKephart just split this out in a recent PR!

You should be able to append & ~AutomationCondition.backfill_in_progress per your request.

[CSRessel]

You're two steps ahead! Fantastic anticipation there 👏