-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[DA] Fix evaluation history UI #22859
Conversation
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.
Did you talk through this approach with someone knowledgeable on the front-end ? Just curious about the trade-off of this intermediate state versus other options
@alangenfeld This intermediate state should only exist for a few releases (until we figure out a more complete redesign) and should only make an impact for people using the new APIs, so my feeling is that the risk level is low (+ it solves an immediate blocking issue) But @salazarm if you have thoughts to the contrary definitely let me know |
sounds reasonable to me if this is an intermediate state |
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.
Roger, I have wasted too much of my life dealing with "should only exist for a few releases" code years after it landed so I feel compelled to poke at stuff like this to makes sure its the best path forward
elif maybe_subset.is_partitioned: | ||
return GrapheneAssetSubset(maybe_subset) | ||
|
||
# TODO: Remove on redesign |
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.
link to a GH issue
@@ -187,7 +197,13 @@ def __init__(self, evaluation: AssetConditionEvaluation, partition_key: str): | |||
self._evaluation = evaluation | |||
self._partition_key = partition_key | |||
|
|||
if partition_key in evaluation.true_subset.subset_value: | |||
if not evaluation.true_subset.is_partitioned: | |||
# TODO: Remove on redesign |
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.
^
Summary & Motivation
Resolves: #22787
The new Declarative Automation framework allows conditions which are evaluated against parents of a given asset. Those parents do not necessarily have the same partitions definition as the child.
The current UI was designed with the expectation that all sub-evaluations would reference the same PartitionsDefinition, and so results in errors when we (e.g.) try to construct a
GraphenePartitionedAssetConditionEvaluationNode
from an evaluation that was actually executed against an unpartitioned asset.We are working on a larger redesign which should help remove this assumption from the core UI model, but for now we can prevent these errors by making it possible to construct a
...PartitionedEvaluationNode
from an unpartitioned evaluation and vice-versa.The end result is a comprehensible UI without errors, although compromises needed to be made (e.g. an unpartitioned row in the partitioned UI ends up being represented as having a "partition key" of the string "None"). This feels like an acceptable state for the short term.
How I Tested These Changes