shivannakarthik opened a new issue, #73060:
URL: https://github.com/apache/airflow/issues/73060
### Description
**Apache Airflow version**
main (also present in released versions reproduced against
providers/google's DataprocDeleteClusterOperator.execute())
**What happened**
When DataprocDeleteClusterOperator.execute() catches any exception other than
google.api_core.exceptions.NotFound during the non-deferrable delete-and-wait
path, it re-raises via:
```
python
except Exception as e:
raise AirflowException(str(e))
```
This discards the original exception's type entirely as far as isinstance()
is concerned, only a flattened string message survives on the raised
AirflowException. The original exception object is still reachable via Python's
implicit exception chaining, but this is an undocumented side effect, not a
supported API, and it silently breaks if the raise statement is ever changed to
raise AirflowException(str(e)) from None.
**What you think should happen instead**
Use explicit exception chaining (raise AirflowException(str(e)) from e) so
that:
The original exception remains recoverable via the documented, idiomatic
__cause__ attribute, not just the implicit __context__ side effect. The
chaining behaviour becomes an intentional part of the code rather than an
accident of how the raise statement happens to be written. This is a small,
backward-compatible hygiene fix that also unblocks cleaner downstream
error-handling for subclasses/consumers that need to distinguish delete-failure
causes (see a related, larger proposal: here).
**How to reproduce**
1. Configure a DataprocDeleteClusterOperator targeting a cluster.
2. Cause hook.wait_for_operation() to raise any non-NotFound exception (e.g.
mock hook.wait_for_operation to raise
google.api_core.exceptions.FailedPrecondition("...")).
2. Observe that type(airflow_exception.__cause__) is None, and the only way
to recover the original exception type is via __context__.
**Operating System**
N/A (library-level issue)
**Versions of Apache Airflow Providers**
apache-airflow-providers-google (current main)
### Use case/motivation
**Why this matters**
Message-string-matching against GCP API errors is precisely the anti-pattern
Airflow's own provider-development guidance steers contributors away from
wording is not version-stable.
This gap blocks clean implementation of any downstream logic that needs to
distinguish delete-failure causes, which currently has no better option than
to also lean on __context__ chaining.
**What happens if this is not addressed**
Every downstream user/subclass author who needs to distinguish delete
failure causes is forced into fragile string-matching, or into relying on an
undocumented Python implementation detail that can silently break with an
unrelated, well-intentioned future edit (e.g., someone "cleans up" the
traceback with from None).
### Related issues
_No response_
### Are you willing to submit a PR?
- [x] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
