Reorder sequence for execution of tasks - example_adf_run_pipeline DAG #405
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I am unable to reproduce issue #366 locally after trying multiple times. Looking at the code, I am understanding that the `run_pipeline_no_wait` and `run_pipeline_wait` try to execute the same pipeline with same name and resources. The `run_pipeline_no_wait` tasks starts the pipeline and does not wait for the pipeline to finish before marking the task as success. My hunch here is that since the pipeline launched by `run_pipeline_no_wait` is still in progress, another immediate attempt by `run_pipeline_wait` task to start the same pipeline is the reason for the failure of the task observed in issue #366. Hence, I am reordering the task sequence so that `run_pipeline_wait` task runs first; the task waits for the pipeline to finish before marking the task as success and then we launch the `run_pipeline_no_wait` task as the downstream task. I would like to push this commit & merge to main so that we can observe in our Astro Cloud deployment's master DAG on whether this solves the problem. If the problem still persists, we will then need to spend additional efforts in investigating the issue.
pankajkoti
requested review from
phanikumv,
bharanidharan14,
rajaths010494 and
pankajastro
as code owners
phanikumv
requested changes
May 31, 2022
Codecov Report
@@ Coverage Diff @@
## main #405 +/- ##
=======================================
Coverage 97.16% 97.16%
=======================================
Files 55 55
Lines 2893 2893
=======================================
Hits 2811 2811
Misses 82 82 Continue to review full report at Codecov.
|
pankajkoti
changed the title
phanikumv
approved these changes
May 31, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I am unable to reproduce issue #366 locally after trying multiple
times. Looking at the code, I am understanding that the
run_pipeline_no_waitandrun_pipeline_waittry to execute thesame pipeline with same name and resources. The
run_pipeline_no_waittasks starts the pipeline and does not wait for the pipeline to finish
before marking the task as success. My hunch here is that since
the pipeline launched by
run_pipeline_no_waitis still in progress,another immediate attempt by
run_pipeline_waittask to start thesame pipeline is the reason for the failure of the task observed in
issue #366. Hence, I am reordering the task sequence so that
run_pipeline_waittask runs first; the task waits for the pipelineto finish before marking the task as success and then we launch
the
run_pipeline_no_waittask as the downstream task.I would like to push this commit & merge to main so that we can
observe in our Astro Cloud deployment's master DAG run on whether this
solves the problem. If the problem still persists, we will then need
to spend additional efforts in investigating the issue.
part of: #366