defer to @catherinewu for final accept to make sure docs are aligned

woof those times are insane

add test case to show re-use of run_id fails with good error

I think this is in a slightly confusing state, I would guess due to how it started vs the latest approach. Sending to you for one more spin for some mix of more tests or renaming / rewording

thanks!

more clean up

pylint hax engage

I have a good feeling that this will feel better all pulled in to one spot

comments inline - I think this will be much clearer if all of this complexity is brought in to one spot with some comments

i take it the new defaults will be in a followup diff?

based on our earlier conversation it seems we may punt on this for release due to the complexity around:

• type based required resource keys
• interactions with default value loading

to your q

rebase on fixes

some fixes, still looking in to lint

ooof this sucks

What if we added a map method to InvokedSolidOutputHandle that raises a NotImplementedError?

can we add some magic to help with the lint warnings?

feedback

forEach -> map

drop forEach

fixup

lint

rebase

rebase

rebase

rebase

If we have map, do we also need forEach?

attempt 2

fix celery

rebase

rebase

rebase

rebase

rebase

can you clarify what you want feedback on at this stage? if there isn't any RFCish stuff left prep this for final review

TEST PLAN
integration
bk

im still worried about keeping these config fields up to date - but ill let you make the final call

rebase, adding step_handle to DagsterEvent shown in D5755

update

the full custom alternative path is less of a concern since that is unlikely - but I do worry that the config setup does not actually work if attempted to be loaded given the provided test plan

is there an escape hatch here for providing a custom one?

rebase

add map

take a note in some form to test this once we publish a prerelease

to your queue post discussion, summary was roughly trying to simplify things a bit by not having overlapping responsibilities between input and object managers, and moving towards a RootInputManager set up where it is only responsible for root loads

ill defer to @max to make the final call

clearing queue for 0.10.0 burn down - request review post release if there is more discussion this can generate

to your queue

Do we need this in for 0.10.0? If yes we should figure out a path forward, likely punting on solving the name issue. If not lets revisit post release

gogogo

alright thats an acceptable enough base line i think - and chances are it will improve a little before launch

We should think about what kind of affordances we might want to put into dagit that prompt people to go deploy the daemon though.

from what i can tell there are no differences to this approach besides the additional typing information on __annotations__
https://docs.python.org/3/library/typing.html

thanks for cleaning up

will let @sandyryza resolve this and D5768

will let @max resolve this and D5764

D5768 / D5764

some more test call sites to patch up but this gives a gist of what this could look like

does the our existing mypy check in buildkite exercise this? should we add a step?

I am pretty sure this is legit given how a lot of the dagstermill impl predates so much of the shifting that has happened around the core execution pathway but I will defer to @max to be sure