-
Notifications
You must be signed in to change notification settings - Fork 16.6k
Fix KeyError when accessing retry_delay on MappedOperator without explicit value#56605
Fix KeyError when accessing retry_delay on MappedOperator without explicit value#56605kaxil merged 3 commits intoapache:mainfrom
Conversation
When querying the API endpoint for mapped tasks (e.g., /api/v2/dags/{dag_id}/tasks/{task_id}),
the server returned a 500 Internal Server Error if the mapped task didn't have an explicit
retry_delay set. The retry_delay property was using direct dictionary access which raised
a KeyError during serialization.
Changed to use .get() with the default value from SerializedBaseOperator (300 seconds)
INFO: 172.18.0.1:47834 - "GET /api/v2/dags/example_dv_simulation_flow/tasks/run_simulation HTTP/1.1" 500 Internal Server Error
ERROR: Exception in ASGI application
raise ResponseValidationError(
fastapi.exceptions.ResponseValidationError: 1 validation errors:
{'type': 'get_attribute_error', 'loc': ('response', 'retry_delay'), 'msg': "Error extracting attribute: KeyError: 'retry_delay'", 'input': , 'ctx': {'error': "KeyError: 'retry_delay'"}}
cc: @kaxil , @vatsrahul1001
When querying the API endpoint for mapped tasks (e.g., /api/v2/dags/{dag_id}/tasks/{task_id}),
the server returned a 500 Internal Server Error if the mapped task didn't have an explicit
retry_delay set. The retry_delay property was using direct dictionary access which raised
a KeyError during serialization.
Changed to use .get() with the default value from SerializedBaseOperator (300 seconds)
|
@dheerajturaga Was the issue you saw on main or 3.1.0? Would be good to add a test case too |
I noticed this on main |
kaxil
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need a test addition, otherwise lgtm
bfca09c to
aa6d79b
Compare
When querying the API endpoint for mapped tasks (e.g., /api/v2/dags/{dag_id}/tasks/{task_id}),
the server returned a 500 Internal Server Error if the mapped task didn't have an explicit
retry_delay set. The retry_delay property was using direct dictionary access which raised
a KeyError during serialization.
Changed to use .get() with the default value from SerializedBaseOperator (300 seconds)
(cherry picked from commit 1ab5bb6)
When querying the API endpoint for mapped tasks (e.g., /api/v2/dags/{dag_id}/tasks/{task_id}),
the server returned a 500 Internal Server Error if the mapped task didn't have an explicit
retry_delay set. The retry_delay property was using direct dictionary access which raised
a KeyError during serialization.
Changed to use .get() with the default value from SerializedBaseOperator (300 seconds)
When querying the API endpoint for mapped tasks (e.g., /api/v2/dags/{dag_id}/tasks/{task_id}),
the server returned a 500 Internal Server Error if the mapped task didn't have an explicit
retry_delay set. The retry_delay property was using direct dictionary access which raised
a KeyError during serialization.
Changed to use .get() with the default value from SerializedBaseOperator (300 seconds)
When querying the API endpoint for mapped tasks (e.g., /api/v2/dags/{dag_id}/tasks/{task_id}),
the server returned a 500 Internal Server Error if the mapped task didn't have an explicit
retry_delay set. The retry_delay property was using direct dictionary access which raised
a KeyError during serialization.
Changed to use .get() with the default value from SerializedBaseOperator (300 seconds)
When querying the API endpoint for mapped tasks (e.g., /api/v2/dags/{dag_id}/tasks/{task_id}),
the server returned a 500 Internal Server Error if the mapped task didn't have an explicit
retry_delay set. The retry_delay property was using direct dictionary access which raised
a KeyError during serialization.
Changed to use .get() with the default value from SerializedBaseOperator (300 seconds)