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

[DA] Fix evaluation history UI #22859

Merged
merged 2 commits into from
Jul 8, 2024
Merged

[DA] Fix evaluation history UI #22859

merged 2 commits into from
Jul 8, 2024

Conversation

OwenKephart
Copy link
Contributor

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 aGraphenePartitionedAssetConditionEvaluationNode 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

Copy link
Member

@alangenfeld alangenfeld left a 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

@OwenKephart
Copy link
Contributor Author

@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

@salazarm
Copy link
Contributor

salazarm commented Jul 8, 2024

sounds reasonable to me if this is an intermediate state

Copy link
Member

@alangenfeld alangenfeld left a 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
Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

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

^

@OwenKephart OwenKephart merged commit 7cc7439 into master Jul 8, 2024
1 check failed
@OwenKephart OwenKephart deleted the owen/fix-evaluation-ui branch July 8, 2024 20:57
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.

Automation UI not working with new AutomationConditions
3 participants