If uploading task logs to S3 fails, retry once

[steveyz-astro]

---

^ 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.

[uranusjr]

I’m not sure this is a good enough solution to be included in the default implementation. Why do I have to retry, and why only exactly once?

A better implementation may be to add a retry: int argument to the operator, and retry that many times (default is 0) with a loop instead.

[steveyz-astro]

@uranusjr

generally the marginal benefit will be for a single retry. s3 oneshot uploads fail randomly very occasionally but failures do happen. Consecutive failures generally indicate a non-ephemeral condition. A single retry would resolve the 90-99% use case with minimal complexity. Multiple retries wouldn't provide much additional benefit.

what do you think of parametrizing with a conf setting similar to encrypt=conf.getboolean('logging', 'ENCRYPT_S3_LOGS')` ?

[potiuk]

generally the marginal benefit will be for a single retry. s3 oneshot uploads fail randomly very occasionally but failures do happen. Consecutive failures generally indicate a non-ephemeral condition. A single retry would resolve the 90-99% use case with minimal complexity. Multiple retries wouldn't provide much additional benefit.

what do you think of parametrizing with a conf setting similar to encrypt=conf.getboolean('logging', 'ENCRYPT_S3_LOGS')` ?

The less options the better. I think It's fine to be hard-coded as a value. The explanation above is good enough but it should find its way to the comment in the code explaining why we try only twice. And even it it is 2, I agree with @uranusjr this is not the best way - it will be less duplication and even less complex if it is in a while or for loop rather than try/except with twice the same code. It's far too easy to miss the second one if we decide to add a new parameter to the call (label for example).

[potiuk]

@uranusjr ?

[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.