Task run exception never catch by Sentry

[EpicFail4Ever]

Under which category would you file this issue?

Providers

Apache Airflow version

3.2.0

What happened and how to reproduce it?

Hello,

I was waiting the PR #57032 to be merged with Sentry fix on the 3.x.
I'm currently testing it and it's not working as I expect.

Settings:

Start an instance with sentry setup :

AIRFLOW__SENTRY__SENTRY_ON=True
AIRFLOW__SENTRY__DSN=<dns>
AIRFLOW__SENTRY__DEBUG=True
AIRFLOW__SENTRY__ENVIRONMENT=local

Start a simple dag that raise an error :

from airflow.sdk import dag, task


@task
def raise_error():
    raise ValueError("This is a test error")


@dag()
def sentry_raise():
       raise_error()


sentry_raise()

The task ends with an error but this is not catch in the sentry session.

What you think should happen instead?

I expected to the the error catch and send to sentry at the end of the task run.

Operating System

Debian GNU/Linux 12 (bookworm)

Deployment

Docker-Compose

Apache Airflow Provider(s)

No response

Versions of Apache Airflow Providers

apache-airflow 3.2.0
apache-airflow-core 3.2.0
apache-airflow-providers-celery 3.17.2
apache-airflow-providers-common-compat 1.14.2
apache-airflow-providers-common-io 1.7.2
apache-airflow-providers-common-sql 1.34.0
apache-airflow-providers-elasticsearch 6.5.1
apache-airflow-providers-fab 3.6.0
apache-airflow-providers-mysql 6.5.1
apache-airflow-providers-postgres 6.6.2
apache-airflow-providers-smtp 2.4.4
apache-airflow-providers-standard 1.12.2
apache-airflow-task-sdk 1.2.0

Official Helm Chart version

Not Applicable

Kubernetes Version

No response

Helm Chart configuration

No response

Docker Image customizations

No response

Anything else?

• It seems to comes from the task Run Sentry decorator function that expect to catch an error raise.
• Then the run function is catching any error in the run and returns it in the third tuple item.

So, error are never raised and nothing is never sent to sentry... 🤗

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[DonHaul]

setting the variables with this env var names worked for us:

this are correct:

AIRFLOW__SENTRY__SENTRY_ON
AIRFLOW__SENTRY__SENTRY_DSN

For the environment setting it like so w/o airflow worked for us (not sure if its a bug):

SENTRY_ENVIRONMENT

for AIRFLOW__SENTRY__DEBUG not too sure

[EpicFail4Ever]

setting the variables with this env var names worked for us:

this are correct:

AIRFLOW__SENTRY__SENTRY_ON
AIRFLOW__SENTRY__SENTRY_DSN

For the environment setting it like so w/o airflow worked for us (not sure if its a bug):

SENTRY_ENVIRONMENT

for AIRFLOW__SENTRY__DEBUG not too sure

For envs :

• The SENTRY_ENVIRONMENT is used for us to distinguish local/staging/demo/prod environments.
• AIRFLOW__SENTRY__SENTRY_DSN and AIRFLOW__SENTRY__DSN are used the same way in config parsing
• AIRFLOW__SENTRY__DEBUG let you see some info on the process with error logs (cf. image bellow)

As seen in the image, the sentry session is setup, an error is generated and the session is flushed with no event catch.

I just linked a PR my thoughts on the feature behavior.