potiuk closed issue #35644: AirflowTaskTimeout should inherit BaseException
instead of Exception?
URL: https://github.com/apache/airflow/issues/35644
--
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
jscheffl commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1873017334
The bug report and discussion seems to be a bit stale. Just looking through
the PR it looks good and reasonable for me. There might be side effects but we
can handle this via a ne
potiuk commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1831033951
So ? Any more concerns :) ?
--
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 spec
potiuk commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1821031787
> The same valid with AirflowException, in some circumstances use this
exception may lead to catch some internal exceptions which should break
something
And yes. This is inev
potiuk commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1820995470
> I've found some grey area of Public interface,
There are probably plenty. It's open for contribution to clarify them as
usual :).
SemVer is very clear about this, ht
Taragolis commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1816807072
I've found some grey area of Public interface, but let's focus on Exceptions
and current case. Many of the things point for the future improvements or
clarifications.
Mayb
potiuk commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1816328009
Just a comment on why we can modify the list - SemVer is not a
`set-in-stone` thing. It's merely a statement of `intention`. Our intention is
to make the "Public Interface" correct.
potiuk commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1816325187
> The problem a bit more deep, all current exceptions is a part of [Public
Interface of
Airflow](https://airflow.apache.org/docs/apache-airflow/stable/_api/airflow/exceptions/index.
Taragolis commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1816227903
The problem a bit more deep, all current exceptions is a part of [Public
Interface of
Airflow](https://airflow.apache.org/docs/apache-airflow/stable/_api/airflow/exceptions/index
potiuk commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1812373741
> To be honest we don't know what the reason in particular this cases. It
could be both:
Yep. There might be many reasons - that's wha I woudl leve #35474 open (and
likely so
Taragolis commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1812305539
> Yeah. But it's not the same issue (or at least I believe it's not) - I
believe the original issue was connected with SIGALRM not being properly
handled by long-running low-leve
potiuk commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1812181064
> That is exactly what a **Option 1** propose 😄
>
Yeah. But it's not the same issue (or at least I believe it's not) - I
believe the original issue was connected with SIGA
hterik commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1812143107
Proposed change here https://github.com/apache/airflow/pull/35653
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub a
smilly2 commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1812013955
**s**
--
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 unsu
smilly2 commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1812013805
>
>
--
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.
Taragolis commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1811957297
That is exactly what a **Option 1** propose 😄
- https://github.com/apache/airflow/issues/35474#issuecomment-1801592051
--
This is an automated message from the Apache Git Se
potiuk commented on issue #35644:
URL: https://github.com/apache/airflow/issues/35644#issuecomment-1811681995
Yes. good idea. Might be worth implementing it.
BTW. There is another problem with tasks running low-level C-code that are
not interrupted by signal (and should be handled in yet
potiuk opened a new issue, #35644:
URL: https://github.com/apache/airflow/issues/35644
### Discussed in https://github.com/apache/airflow/discussions/35643
Originally posted by **hterik** November 14, 2023
### Apache Airflow version
2.7.3
### What happened
potiuk closed issue #35625: AirflowTaskTimeout should inherit BaseException
instead of Exception?
URL: https://github.com/apache/airflow/issues/35625
--
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
hterik opened a new issue, #35625:
URL: https://github.com/apache/airflow/issues/35625
### Apache Airflow version
2.7.3
### What happened
Assume following code runs inside airflow task:
```py
errors = []
for item in items_to_process:
try:
p
20 matches
Mail list logo
