We are molting (searching for alternatives to knife emoji, "kill", "rip out", etc.). This removes the ability to set run_id or step_keys_to_execute when invoking execute_pipeline. Note that the GraphQL layer never used this codepath. Adds a convenience method, execute_run, to make the actual codepath clearer.
ah you meant 0.8.0.
honestly I think we can do it in the next cut. I would surprised if users do that a lot.
Sidenote: This would be good stuff to collect telemetry on so we have visibility into how much we are going to thrash users.
if we're cool switching in to "master is 0.8.0" mode we can have execute_pipeline_def for executing defs directly and make *execute_pipeline* only take ExecutablePipeline
lets add a changes.md entry too
nit: would it be better to push these private methods to the bottom and open the file with the brief guide
why cant this just be event_list = list(_execute_run_iterator_with_plan(...)) ?
I dont understand what these "supports reexecution" & its column values mean
feels bad that we have to import this _ method - should this be execute_run since we dont need the result?
maybe we should have _execute_run_plan_with_plan_iterator and this should be _execute_run_with_plan_sync
it took me so long to piece together this refactor - im not sure how much more verbose / clearer names would help but its worth a shot
yep, this stuff is a mess. the only thing this does that execute_run_iterator doesn't is pull out the pipeline_context so bits of it can be pasted into the PipelineExecutionResult's scoped_pipeline_context. ultimately this should go away once we get file manager and intermediates manager properly scoped. in the interim, we could fix it by refactoring execute_run_iterator to be an object -- i may just put a diff up for that