Add sensor for AWS Batch (#19850)

[yeshbash]

Adds a sensor implementation to ask for the status of an
AWS Batch job. The sensor will enable DAGs to wait for the
batch job to reach a terminal state before proceeding to the
downstream tasks.

closes: #19850

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, 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 UPDATING.md.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
Here are some useful points:

• Pay attention to the quality of your code (flake8, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it’s a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[eladkal]

I think it would be better to manage the statuses on the hook level.
The hook itself also has a function that require the same definitions:

airflow/airflow/providers/amazon/aws/hooks/batch_client.py

Lines 248 to 255 in 0df50f4

	if job_status == "SUCCEEDED":
	self.log.info("AWS batch job (%s) succeeded: %s", job_id, job)
	return True
	if job_status == "FAILED":
	raise AirflowException(f"AWS Batch job ({job_id}) failed: {job}")
	if job_status in ["SUBMITTED", "PENDING", "RUNNABLE", "STARTING", "RUNNING"]:

So we should have one place to define it for both.

[yeshbash]

Good point - I will define these in AwsBatchClientHook and reference it.

While making the change, I noticed that the hook also uses two additional combinations of state values for its own methods

1. poll_for_job_running: checks for ["RUNNING", "SUCCEEDED", "FAILED"].
2. poll_for_job_complete : checks for ["SUCCEEDED", "FAILED"]

I'm planning to create the following state definitions to cater to all cases. Let me know if you think otherwise and leaving the above two methods the same would be better.

    FAILURE_STATE = 'FAILED'
    SUCCESS_STATE = 'SUCCEEDED'
    RUNNING_STATE = 'RUNNING'
    INTERMEDIATE_STATES = (
        'SUBMITTED',
        'PENDING',
        'RUNNABLE',
        'STARTING',
        RUNNING_STATE,
    )

[ferruzzi]

I'm not overly familiar with Batch yet. Is there a use case for setting a target state? Rather than just returning success/working/failed, is it desirable to have the option to check if it is currently RUNNING, for example?

[yeshbash]

This sensor's objective is to poke until the job reaches a logical end - success/failure. In this context, I can't think of a use-case where matching against any other target state can be useful. There could be other places where we want to check against a target state and the AwsBatchClientHook already has a method for this.

airflow/airflow/providers/amazon/aws/hooks/batch_client.py

Line 321 in 0df50f4

def poll_job_status(self, job_id: str, match_status: List[str]) -> bool:

Let me know if I misunderstood your comment.

[yeshbash]

I was looking at emr_sensor and that helped me understand your question better. Are you asking if making the terminal states configurable such that the sensor can return true/false based on it?

I don't know a definitive answer but this is my thought process

• I could see it useful for DAGs which follow a fire-and-forget pattern to launch the job.
• In fire-and-forget scenarios, would there be a need to use a Sensor? - I don't think so
• In the case of EMR, a cluster RUNNING could be a logical terminal state for long-running clusters. On the contrary, the batch is for ephemeral tasks and the same might not make sense
• I see AwsBatchOperator providing this option through the waiter argument.

With this, I'm inclining to say that a configurable terminal state might not be useful here. Let me know your thoughts

[ferruzzi]

I appreciate the detailed reply; that makes sense.

As an example of what I was thinking: the EKS Nodegroup sensor can be used to wait for the nodegroup to go "creating" so it can send the command to start spinning up a second, or wait to go "active" and trigger a task to run on it, or wait to go "nonexistent" so the cluster it is attached to could be deleted. I was wondering if Batch had a usecase for adding similar logic, but it sounds like that may not be the case.

Carry on, and sorry for the distraction. 😄

[eladkal]

LGTM
@yeshbash would you mind adding also example dag and docs?
you can use GCS docs as reference

[github-actions]

The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest main or amend the last commit of the PR, and push it with --force-with-lease.

[boring-cyborg]

Awesome work, congrats on your first merged pull request!