-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
add BulkActionStatuses COMPLETED_SUCCESS and COMPLETED_FAILURE #24365
add BulkActionStatuses COMPLETED_SUCCESS and COMPLETED_FAILURE #24365
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @jamiedemaria and the rest of your teammates on Graphite |
8ede603
to
c0f3355
Compare
c0f3355
to
ea8ea41
Compare
@prha @sryza two discussion topics we can either chat about in this PR or in a meeting this week:
I dont think either of these have to block this PR, but want to mark these as topics to discuss at some point |
ea8ea41
to
2a8e135
Compare
@@ -130,6 +132,10 @@ def to_dagster_run_status(self) -> GrapheneRunStatus: | |||
return GrapheneRunStatus.STARTED # pyright: ignore[reportReturnType] | |||
if self.args[0] == GrapheneBulkActionStatus.COMPLETED.value: # pyright: ignore[reportAttributeAccessIssue] | |||
return GrapheneRunStatus.SUCCESS # pyright: ignore[reportReturnType] | |||
if self.args[0] == GrapheneBulkActionStatus.COMPLETED_SUCCESS.value: # pyright: ignore[reportAttributeAccessIssue] |
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.
I'd like to think of other potential solutions for this conversion (if we maintain the runStatus
graphene attr i mentioned in my other comment). It looks like we'll need to convert run statuses to bulk action statuses too for filtering, so i think a consistent solution is in order. Another thing that i can stack on, but isn't strictly required for this PR
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.
The two lines added here look fine to me. But wondering more generally what the filtering experience looks like -- if I filter to queued runs, do I see runs in the backfill? Or do I see the whole backfill display as a single run if any run is queued? Or something else?
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.
the scheme were going with for filtering is that the row-level object is what gets filtered. So if you are in the combined single runs + backfills view, and filter for queued status, you will only see single-runs that have queued status. and no backfills (even if the backfill has queued runs)
2a8e135
to
0923a4b
Compare
0923a4b
to
f097359
Compare
@@ -130,6 +132,10 @@ def to_dagster_run_status(self) -> GrapheneRunStatus: | |||
return GrapheneRunStatus.STARTED # pyright: ignore[reportReturnType] | |||
if self.args[0] == GrapheneBulkActionStatus.COMPLETED.value: # pyright: ignore[reportAttributeAccessIssue] | |||
return GrapheneRunStatus.SUCCESS # pyright: ignore[reportReturnType] | |||
if self.args[0] == GrapheneBulkActionStatus.COMPLETED_SUCCESS.value: # pyright: ignore[reportAttributeAccessIssue] |
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.
The two lines added here look fine to me. But wondering more generally what the filtering experience looks like -- if I filter to queued runs, do I see runs in the backfill? Or do I see the whole backfill display as a single run if any run is queued? Or something else?
924c8a3
to
8322a44
Compare
8322a44
to
8f9343e
Compare
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.
LGTM
8f9343e
to
7b447bb
Compare
## Summary & Motivation Updates the FE to display the `COMPLETED_SUCCESS` and `COMPLETED_FAILED` statuses in the downstream PR ## How I Tested These Changes Backfill run after updating the UI shows `Succeeded` status. Backfill run before the UI update is still `Completed`. Note that we changed the language to `Success` instead of `Succeeded` so this screenshot is slightly out of date <img width="1576" alt="Screenshot 2024-09-12 at 12 40 50 PM" src="https://github.com/user-attachments/assets/fbf63a4f-17da-4428-9feb-11c7da7c186c"> ## Changelog Insert changelog entry or "NOCHANGELOG" here. - [ ] `NEW` _(added new feature or capability)_ - [ ] `BUGFIX` _(fixed a bug)_ - [ ] `DOCS` _(added or updated documentation)_
Summary & Motivation
Adds two new BulkAction statuses
COMPLETED_SUCCESS
andCOMPLETED_FAILURE
to expand on the existingCOMPLETED
status. This allows us to store the more fine grained information of if the backfill completed with some run failures or if the backfill completed with all runs successful.How I Tested These Changes
Changelog
Insert changelog entry or "NOCHANGELOG" here.
NEW
Backfill status will now distinguish between a completed backfill with all runs successful, and completed backfill with some run failures. Previously, these were displayed as the sameCompleted
status. This change only applies to new backfills. Backfills that have already completed will still show aCompleted
status.