:py:mod:`astronomer.providers.amazon.aws.hooks.batch_client`
============================================================

.. py:module:: astronomer.providers.amazon.aws.hooks.batch_client


Module Contents
---------------

Classes
~~~~~~~

.. autoapisummary::

   astronomer.providers.amazon.aws.hooks.batch_client.BatchClientHookAsync




.. py:class:: BatchClientHookAsync(job_id, waiters = None, *args, **kwargs)

   Bases: :py:obj:`airflow.providers.amazon.aws.hooks.batch_client.BatchClientHook`, :py:obj:`astronomer.providers.amazon.aws.hooks.base_aws.AwsBaseHookAsync`

   Async client for AWS Batch services.

   :param max_retries: exponential back-off retries, 4200 = 48 hours;
       polling is only used when waiters is None
   :param status_retries: number of HTTP retries to get job status, 10;
       polling is only used when waiters is None

   .. note::
       Several methods use a default random delay to check or poll for job status, i.e.
       ``random.sample()``
       Using a random interval helps to avoid AWS API throttle limits
       when many concurrent tasks request job-descriptions.

       To modify the global defaults for the range of jitter allowed when a
       random delay is used to check Batch job status, modify these defaults, e.g.:

           BatchClient.DEFAULT_DELAY_MIN = 0
           BatchClient.DEFAULT_DELAY_MAX = 5

       When explicit delay values are used, a 1 second random jitter is applied to the
       delay .  It is generally recommended that random jitter is added to API requests.
       A convenience method is provided for this, e.g. to get a random delay of
       10 sec +/- 5 sec: ``delay = BatchClient.add_jitter(10, width=5, minima=0)``

   .. seealso::
       - `Batch <https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/batch.html>`_
       - `Retries <https://docs.aws.amazon.com/general/latest/gr/api-retries.html>`_
       - `Exponential Backoff And Jitter <https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/>`_

   .. py:method:: monitor_job()
      :async:

      Monitor an AWS Batch job
      monitor_job can raise an exception or an AirflowTaskTimeout can be raised if execution_timeout
      is given while creating the task. These exceptions should be handled in taskinstance.py
      instead of here like it was previously done

      :raises: AirflowException


   .. py:method:: check_job_success(job_id)
      :async:

      Check the final status of the Batch job; return True if the job
      'SUCCEEDED', else raise an AirflowException

      :param job_id: a Batch job ID

      :raises: AirflowException


   .. py:method:: delay(delay = None)
      :staticmethod:
      :async:

      Pause execution for ``delay`` seconds.

      :param delay: a delay to pause execution using ``time.sleep(delay)``;
          a small 1 second jitter is applied to the delay.

      .. note::
          This method uses a default random delay, i.e.
          ``random.sample()``;
          using a random interval helps to avoid AWS API throttle limits
          when many concurrent tasks request job-descriptions.


   .. py:method:: wait_for_job(job_id, delay = None)
      :async:

      Wait for Batch job to complete

      :param job_id: a Batch job ID
      :param delay: a delay before polling for job status

      :raises: AirflowException


   .. py:method:: poll_for_job_complete(job_id, delay = None)
      :async:

      Poll for job completion. The status that indicates job completion
      are: 'SUCCEEDED'|'FAILED'.

      So the status options that this will wait for are the transitions from:
      'SUBMITTED'>'PENDING'>'RUNNABLE'>'STARTING'>'RUNNING'>'SUCCEEDED'|'FAILED'

      :param job_id: a Batch job ID
      :param delay: a delay before polling for job status

      :raises: AirflowException


   .. py:method:: poll_for_job_running(job_id, delay = None)
      :async:

      Poll for job running. The status that indicates a job is running or
      already complete are: 'RUNNING'|'SUCCEEDED'|'FAILED'.

      So the status options that this will wait for are the transitions from:
      'SUBMITTED'>'PENDING'>'RUNNABLE'>'STARTING'>'RUNNING'|'SUCCEEDED'|'FAILED'

      The completed status options are included for cases where the status
      changes too quickly for polling to detect a RUNNING status that moves
      quickly from STARTING to RUNNING to completed (often a failure).

      :param job_id: a Batch job ID
      :param delay: a delay before polling for job status

      :raises: AirflowException


   .. py:method:: get_job_description(job_id)
      :async:

      Get job description (using status_retries).

      :param job_id: a Batch job ID
      :raises: AirflowException


   .. py:method:: poll_job_status(job_id, match_status)
      :async:

      Poll for job status using an exponential back-off strategy (with max_retries).
      The Batch job status polled are:
      'SUBMITTED'|'PENDING'|'RUNNABLE'|'STARTING'|'RUNNING'|'SUCCEEDED'|'FAILED'

      :param job_id: a Batch job ID
      :param match_status: a list of job status to match
      :raises: AirflowException