Simultaneous invocation can cause inconclusive results

[nikhil-gupta2]

In the function wait_for_workflow_to_finish we are getting the last/latest workflow run...

Imagine we have Repo A, B & C. A & C both invoke the workflow from B let's say almost @ the same time. With the current logic we will never know which run was initiated by which Repo.

[keithconvictional]

Thanks for opening the issue. You are right, there is the potential for A pulling in the results from trigger of C. In terms of solution, we can capture the run_id when calling the trigger and watch till that specific run finishes.

[nikhil-gupta2]

Hey, thanks for the reply. I don't think the workflow dispatch returns a run_id so it might not be possible to wait for a specific run without knowing the run_id...
How I have solve this before is by waiting for a check_run...
The workflow name is a constant and cannot be changed but the job name can be dynamic... So u can pass some value to the workflow dispatch and concatenate the job name with it... Then u poll/wait for a check_run with that specific name i.e. job_name+input_value... Input could be a SHA so the job name will always be unique...

[djthornton1212]

I think I've encountered something similar, but instead a race condition every so often the workflow ID returned matches a previously run job.

For instance, I was testing a workflow_dispatch yesterday that failed. I made modifications today and ran a new dispatch job which was successful when you view the dispatched repository, though the calling job says it failed and shows the workflow ID from yesterday's failed job. It's really weird.

Notice the workflow ID and triggered time stamp (and that it was triggered by a push):

Now here's the job run about 30 minutes ago (workflow ID matches:

Then there's the actual job that ran which was successful:

I actually saw this happed a few days ago and ignored it as some space anomaly, but now I feel as though I can't trust this. I don't know when it will give me a false negative/positive.

[NotNils]

@djthornton1212 we need this PR to mitigate some of these issues #37

[djthornton1212]

@NotNils Thank you. I'll keep my eyes on that PR.

[rabih]

Assuming this has been cleared :)