Fix _get_count in sensor_helper.py

[fuatcakici]

Fixes an overlooked part of #39616

Currently, the _get_count function in sensor_helper.py does not return the number of the Dag Runs where all the sub tasks in a task group for all the datetimes given in the dttm_filter have succeeded, but instead just returns 1 if they are all complete. However, this is not the expected behaviour wherever this function is used (namely in the run function in WorkflowTrigger and poke function in ExternalTaskSensor)

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

[eladkal]

@pankajastro @nathadfield Can you check if this fix still needed?

[nathadfield]

@eladkal Well, I fixed the original issue. It seems this is related to something I overlooked but I'm not aware that it's a problem.

[fuatcakici]

@nathadfield yes, I was also waiting for that issue to be fixed, so thanks! But basically here, there are no issues if there is only one execution date set for the execution_dates parameter in the WorkflowTrigger. But once you set more than one execution date, it will just hang since _get_count will give 1 once all the tasks finish, but WorkflowTrigger will wait until it gives len(execution_dates), which will not happen.

[nathadfield]

@fuatcakici Ok, well, this is your PR but it originally had some issues. Can I suggest that you rebase it and then this should trigger the tests again?

[fuatcakici]

@nathadfield Rebased 🙂

[nathadfield]

@fuatcakici Great! It looks like all the tests passed too although I don't have the ability to merge. Maybe @eladkal or @pankajastro might be able to oblige?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

[eladkal]

@fuatcakici can you rebase and resolve conflicts?
Also we need unit test to avoid regression

[fuatcakici]

@eladkal Rebased once again and all the tests succeeded 🙂 There are of course many changes happening in real time so it is virtually impossible for the branch to stay constantly up-to-date

[eladkal]

Since @nathadfield confirmed it's a bug fix, I am happy to merge once you add a unit test to cover this change. This is needed to making sure we won't have future regression

[eladkal]

@fuatcakici can you fix static checks?

[fuatcakici]

@eladkal Static checks fixed and the tests seem to have run successfully 🙂

[Lee-W]

left one nit. overall looks good. but would be nice to have another pair of eyes to look into it

[fuatcakici]

Hi @eladkal @Lee-W, I noticed that the milestone for which this change would be present in has been removed. Do you know for which upgrade we can expect this change?

[eladkal]

Hi @eladkal @Lee-W, I noticed that the milestone for which this change would be present in has been removed. Do you know for which upgrade we can expect this change?

This PR is not part of airflow core but with airflow standard provider.
so it will be included in the next provider release.