Exposing a configurable priority key is actually pretty risky and will result in a lot of replicated config.

So the crux of it is:

• we do dagster/priority and it works for the core executors but (probably?) none of the others which leads to an unfortunate expectation mis-match in a not clearly communicated way (keys just ignored)
• we do separate keys for each executor to align expectations ie dagster/in-process/priority, dagster-in-process/priority, whatever but thats aesthetically unfortunate and leads to having to set all keys to support different execution modes

what should the predefined keys be for the in process and multi process engines? I wasn't happy with what I came up with which motivated me to punt it out to config

move sorting out to individual engines. use config to drive what key to use for prioirty on default engines

changes here all seem reasonable to me

I think this is better

rebase

dont have strong feelings - but the complexity cost of warn here feels pretty minimal so i maybe lean that way

can you explain automated comment. i think i am missing something

different approach

flipping the bool does make the change not quite automated - not sure where that nets out on hard break vs deprecate

personal opinion: the blue color is a bit agro i would try to tone it down a bit

revert change to other code

fix old code and add comments to tests

different approach to handle mock issue

I'm cool with this if 'handle-like' names are actually the same as the handles - if not it would be good to get an explanation of what exactly is going on there

more ordered dict

cant repro locally add some logging for BK

proper way to test this? This error only comes up at either schedule page load time or schedule execution time because that's when we run environment_dict_fn.

py2 fixes?

priority test

ordered dict

set mock to None when not found

does the non-slim have gcc?

apply workaround

more debug

back to debugging

remove debug

seems fine, although isn't this a slightly different fix than the warning text indicates?

canary

set service account name

I would just look through the other tests in dagster_graphql - python_modules/dagster-graphql/dagster_graphql_tests/graphql/test_run_cancellation.py is probably a relevant example

god damn yaml templates

rebase

just spitballing ideas one thing we could do is keep the box pinned but to the left but change where the shading starts? What i want visually communicated when these things are waiting on eachother for not-data reasons is:

from use - if you execute the sleepy toy pipeline with the default config which uses inprocess engine - the four parallel steps happen sequentially which is not communicated in the waterfall timed view at all since we pin no the left alignment. Is this something worth addressing now or in a subsequent diff?

this seems fine, double check if you need to add the check stuff

special case singurlar input_def

rebaesw

rm print()

update serdes and seven to better handle py2

nice - just make sure to cleanup unused stuff

rebase + comment

it seems like something bad is happening in changed.md thats causing the autoformatter to go nuts