Adjusted the EMRServerlessStartJobOperator to cancel failed jobs

[dominikhei]

---

closes: #42401

I have introduced a cancel_job method to the EMRServerlessHook, which wraps the cancel_job_run method from boto3.

In cases of a non deferrable job run, if an Exception that waiter_max_attempts has been reached is thrown, cancel_job is executed. If deferrable is set to True, the cancellation logic is placed inside execute_complete, as this method evaluates the job state in this case.

[vincbeck]

I feel like this is a very opinionated decision. I am wondering if this is not something the user should set by using on_failure_callback and not us to take this decision.

I'd like to hear more thoughts on that from others.

[dominikhei]

I feel like this is a very opinionated decision. I am wondering if this is not something the user should set by using on_failure_callback and not us to take this decision.

I'd like to hear more thoughts on that from others.

Apologies if there is an obvious answer, but is there a use case where you would want the job to not be cancelled in EMR if a new one is created due to retries, now running / pending concurrently?

[vincbeck]

I feel like this is a very opinionated decision. I am wondering if this is not something the user should set by using on_failure_callback and not us to take this decision.
I'd like to hear more thoughts on that from others.

Apologies if this is an obvious question, but is there a use case where you would want the job to not be cancelled in EMR if a new one is created due to retries, now running / pending concurrently?

Hard to know all the different user use cases but I think you're correct, I do not see any, so I am probably wrong in my perception :)

[dominikhei]

I feel like this is a very opinionated decision. I am wondering if this is not something the user should set by using on_failure_callback and not us to take this decision.
I'd like to hear more thoughts on that from others.

Apologies if this is an obvious question, but is there a use case where you would want the job to not be cancelled in EMR if a new one is created due to retries, now running / pending concurrently?

Hard to know all the different user use cases but I think you're correct, I do not see any, so I am probably wrong in my perception :)

That’s true, there’s definetly a point in letting the user decide, albeit introducing more complexity. As you said lets wait on other opinions :)