dimberman commented on code in PR #27428:
URL: https://github.com/apache/airflow/pull/27428#discussion_r1104630309
##########
airflow/api_connexion/schemas/task_instance_schema.py:
##########
@@ -33,6 +33,14 @@
from airflow.utils.state import State
+class _ExecutorConfigField(fields.String):
+ def _serialize(self, value, attr, obj, **kwargs):
+ try:
+ return super()._serialize(value, attr, obj, **kwargs)
+ except Exception:
Review Comment:
It's generally bad form to catch all Exceptions because if you get an
exception didn't expect it would be better for things to fail in a _big_ way
instead of a controlled way. A lot of linters explicitly call this out. I
think it's reasonable to catch the exceptions we expect to catch given the
knowledge we have instead of a broad Exception.
##########
airflow/api_connexion/schemas/task_instance_schema.py:
##########
@@ -33,6 +33,14 @@
from airflow.utils.state import State
+class _ExecutorConfigField(fields.String):
+ def _serialize(self, value, attr, obj, **kwargs):
+ try:
+ return super()._serialize(value, attr, obj, **kwargs)
+ except Exception:
+ return "{}"
Review Comment:
I'd rather an exception if possible. Even if documented it still fells...
clunky...
##########
tests/api_connexion/endpoints/test_task_instance_endpoint.py:
##########
@@ -41,6 +41,11 @@
DEFAULT_DATETIME_STR_2 = "2020-01-02T00:00:00+00:00"
+class _BadExecutorConfig:
+ def __str__(self):
+ raise Exception()
Review Comment:
If anything, we can create a custom exception class here. Somehting like
`BadExecutorConfigException(AirflowException)`.
--
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]