Update snapshots

Sounds good! Yep, I think you now have to press enter after typing freeform text to apply it + search, though that may be best for realistic scenarios with lots of logs

• Properly support filtering by type and step
• Rebase

This looks great! Just added a few comments on the JS side of things—very cool to see multiple selection in the gaant view! I think that some of the changes to the "structured contents of the search bar" overlap with work I did but it might be easier for you to land this first, will check and see.

Just a few drive-by comments, this looks good to me otherwise!

Fix scroll bars

Ooh good comment @alangenfeld, didn't see those scrollbars on my machine, will fix before landing this!

Fix generated types

• Improved box colors
• Improved jump-to-line that does not remove contextual help and reliably puts the line at the top of the editor
• Option to show only incorrectly configured boxes

LGTM!

• Add a hover highlight to the log rows, weaken debounce so it doesn't seem slow
• Order the markers for display so that later markers are stacked on top in the DOM and hoverable
• Improve the fog of war color so it has the same slight bluish tint as our other grays

Hey @alangenfeld , @prha , this should be ready for review again! Per our conversation yesterday there have been a handful of changes:

• Add preparing step state, make logs and UI use new consistent skipped color
• Debounce the hovering of logs
• Split apart retried steps, clean up rendering a bit

• Better informational color
• Indicate retries by colorizing the box gray=>green or gray=>red
• Handle markers appearing multiple times due to retries
• Highlight the current time as you hover over logs so it's easier to tie logs to the viz.

Looks good to me! I think we could definitely iterate on the design a bit and make it more of a vertical timeline (ala old execution plan), but the React parts look solid and we can play with that later. Also if you're in need of a very cheap way to fix those uppercase SUCCESS, etc. labels, you can do <span style={{textTransform: 'capitalize'}}>{text.toLowercase()}</span> and I wouldn't judge (or treat them as an enum and map from value => display value in a dict)

Hey! Just wanted to chime in — I think that the final approach here (using the DOM APIs to "click" the select when the shortcut is activated) is probably the best. I ran into this with the PipelineJumpBar as well. Ideally, the select Component would expose public methods (class components can have instance methods that you can call to imperatively, eg myCustomComponentRef.zoomToCenter()) OR allow for controlled usage. Blueprint's Select component is more or less a black box, and activating it via the DOM is the least-likely-to-break hack, since it should fundamentally always respond to a click event.

Add comment

Terrible at python today

Try from dagster venv

Update dagit router smoke test

• To be on the safe side, change local storage keys so we don’t need a migration
• Update tests to a valid playground path
• Fix “/setup” handling

LGTM! Thanks for fixing 🙌

• Pull pipeline out of session, fix issue with initial empty states

Hmm will try reverting my local storage and see if I can repro, that's an odd one.

Accepted with one minor nit!

• Merge branch 'master' of github.com:dagster-io/dagster into sfbg/gaant-v2
• Toggle query when double clicking
• Slowest path should only consider finished nodes

In D1997#51517, @schrockn wrote:

So I think a reasonable resolution to "undo" the selection of *foo*: If you double click again it toggles back to "*"

Test failures appear spurious?

• Add comments, address diff feedback
• Conditionally add preset queries, don’t add any that are “”
• Fix inifinite traversal - algo is visiting nodes repeatedly
• Clearing a preset should reset filter to “*”
• Add basic double-click-to-query behavior
• Pass the current time through layout adjustment, tick continuously for smooth effect

Update types

• Fix button label on the subset selector
• Don’t assume step state transition logs will arrive in the right order
• Put the “Re-execute” / “Cancel” / “Resume” buttons back in the old UI
• Add a lint error when we hit the error display limit in the config editor

Added a message showing that errors are truncated!

Looks good! This should allow us to fix the UI. Is the mode part of the execution selection or is that a parallel setting? Had expected to see that in here but maybe it's just because we've been showing them together in the UI.

• Merge branch 'master' of github.com:dagster-io/dagster into sfbg/expanded-composites-less-fun

• Merge branch 'master' of github.com:dagster-io/dagster into sfbg/gaant

Rebase

• Rework CSS on config editor help
• Fix min heights / behavior of the gaant UI when shrunk to 0 size
• Add split panel controls for focusing first or second panels fast
• Throw a few gradients in for good measure
• Much more realistic timed-waterfall

Looks good! Just a few minor suggestions 👍

• Rename to “explode” composites and only show when it’d do something
• Update tests

Will update this to address the feedback! Re: full reload, I think that the flashing loading indicator is annoying but also not realistic. For large pipelines this will probably take many seconds to switch over because it has to load every solid handle. I don't think we can do much of a transition because the graph shape changes, and navigating / continuing to play with the DAG while it loads isn't productive because it'll blow away your state when it replaces the graph. I think we should probably revisit better loading state when we make it expand the composites in-place via fancier edits to the rendering algo, since that'd allow for more of a transition!

Cleanup & Update tests

Ahh @alangenfeld that's a good question—for the serial execution engine displaying the dependency graph isn't quite what we want. Could we make the execution plan to include the order it plans to execute steps? Right now the plan doesn't encode enough information for us to know what the true parallelism / timing will look like (at least I don't think?) We could detect the serial execution engine and show them in a waterfall, but we might get the order wrong I think?

• Use fewer large nested functions in Gaant layout code

Comment Gaant layout algo