Page MenuHomePhabricator

[dagit] Allow snapshots to re-run even if the snapshot ID is mismatched
ClosedPublic

Authored by dish on Wed, Oct 14, 9:20 PM.

Details

Summary

When viewing a run, we currently disable the re-execution button if the snapshot ID doesn't match the current snapshot ID for that pipeline in the active repo.

An issue here is that a run on a solid subselection will produce a different snapshot ID from the parent pipeline, which means this button will always end up being disabled when trying to re-run that subselection.

Instead, show a tooltip warning but allow the re-execution to occur.

Test Plan

View a historical run, verify that the warning appears and that I am able to re-execute the run.

Diff Detail

Repository
R1 dagster
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

dish requested review of this revision.Wed, Oct 14, 9:26 PM
js_modules/dagit/src/runs/RunActionButtons.tsx
205–209

this seems unfortunate - but i am guessing is harder to solve without the deeper refactors and matches the previous behavior?

alangenfeld added inline comments.
js_modules/dagit/src/runs/RunActionButtons.tsx
164

drop the !! since this is bool

This revision is now accepted and ready to land.Wed, Oct 14, 9:31 PM
js_modules/dagit/src/runs/RunActionButtons.tsx
205–209

Well, the previous code (before https://dagster.phacility.com/D3882) did effectively the same thing, it just didn't define the {tooltip, icon} object in a separate function, so disabled didn't have to be housed alongside.

The icon and tooltip are also already very "button" things, so this is just tacking on another. Doesn't bother me too much.

js_modules/dagit/src/runs/RunActionButtons.tsx
205–209

to clarify - I was speaking to disabling the button even though we know there is a pipeline in a different repository in the workspace that just happens to not be selected

js_modules/dagit/src/runs/RunActionButtons.tsx
205–209

Ahhh, I see. Yep, that is unfortunate.

I think if we flatten out all workspace-level objects to be uniquely identifiable by e.g. repo:location:pipeline_name, then we can stop using a single-repo context at the top level, and stop requiring people to switch in order to perform operations on objects elsewhere in their workspace. So hopefully the direction I'm going to try to take things will be useful here.