Is there somewhere else I can get a handle

nit maybe 'queue' or 'run_queue'? the 'ing' part feels a little out of place compared to the rest

one thing to think about here is that in this scheme, hanging runs (e.g. the gRPC server crashes while its executing and nothing finishes it) go from a minor annoyance to something that will potentially hold up the queue. We may need some kind of cleanup process that detects hanging runs for that reason (not blocking for this)

you could also use overrides={"run_launcher": ...} on instance_for_test and sub in an InMemoryRunLauncher here (might need to pull it out of the test where its currently used)

so the scheduler ended up with its own dagster-scheduler CLI entry (mostly because schedule vs. scheduler was confusing, plus the fact that it was a separate standing process)

maybe this should end up in that dagster-scheduler group instead? esp if we think they are going to end up being deployed together as part of the same process (along with triggers as well)

we are going to want to make this non-optional as part of this work, right? maybe not at first since it may be a breaking change, but as part of 0.10.0?

rm

i think we can just leave this out yeah, seems separate

meh, is there a concrete benefit to this?

^^ still true, and probably better than mocking out functions

ya agree we need to figure out something cohesive around this

what unit is this?

set types for these options

hm i wonder if there are cases where its tough to guarantee this is easily resolvable - in the near term the only assertion that matters is QUEUED status requires an origin

That makes sense to me

Yes, will add a note

Just to decrease the size of the payload, probably not a big deal. It would now need <run_id, pipeline_origin>