Adds a generic tags attribute on PipelineRunData, which stores the tags set on executionParams.executionMetadata.tags. Also stores a dagster/scheduleId tag on pipeline runs that were initiated by a schedule.
we should probably do a shared interface here
just throwing ideas out there since it feels a bit off
assert status probably
this comment doesnt make any sense - think i forgot to remove it
or we could align to the status enum - but i think failure and success probably have the same fields - not sure if active has anything different though conceptually you should only be able to subscribe on active
If this implementation looks good, I can rename the interface and implementors as suggested, since a rename of PipelineRun would require a lot of changes throughout the codebase
After looking at this I'm still very unclear as to why we need a new "Planned" pipeline run graphql type. Can it not just be a different state?
The main idea is communicating in the GraphQL schema what information you have access to from a "start pipeline" mutation ie results are not present yet. Internally PipelineRun is a tagged type but this change would make the GraphQL type be separate types with a common interface.
@sashank lets split out the GraphQL schema change in to its own diff since its worth more discussion and shouldnt block the tags storage change
I don't understand why this is necessary or required. if we are "updating" a run to be "not started" what does that mean?
i think dagster.utils.merge_dict would be more elegant here
why is this not just a run_id check? all the other properties you are checking are immutable w/r/t run_id