Improve error handling and logging in CommsDecoder interface

Resurrect #45927 and extend it.

Every request should have a response that the client reads.

We need the ability to pass/send errors from Supervisor to the task code (for instance if there is an error performing an action, or if the XCom can't be found) -- right now each end point handles this itself in a different way.

airflow/task_sdk/src/airflow/sdk/api/client.py

Lines 267 to 282 in eb05869

    
           except ServerResponseError as e: 
        
               if e.response.status_code == HTTPStatus.NOT_FOUND: 
        
                   log.error( 
        
                       "XCom not found", 
        
                       dag_id=dag_id, 
        
                       run_id=run_id, 
        
                       task_id=task_id, 
        
                       key=key, 
        
                       map_index=map_index, 
        
                       detail=e.detail, 
        
                       status_code=e.response.status_code, 
        
                   ) 
        
                   # Airflow 2.x just ignores the absence of an XCom and moves on with a return value of None 
        
                   # Hence returning with key as `key` and value as `None`, so that the message is sent back to task runner 
        
                   # and the default value of None in xcom_pull is used. 
        
                   return XComResponse(key=key, value=None)

for example shouldn't be handled in the API Client, but it should expose/raise the 404 to the Task itself and it should be handled there

and have SUPERVISOR_COMMS.lock too.

(https://github.com/apache/airflow/pull/49005/files#r2035343236)

@ashb

@ashb a lot of this has been handled already via: #51699?

Do we have more to do for 3.0.4? Or can we move this one to 3.1?

@amoghrajesh

@amoghrajesh I think to mark this as closed we need to at least do these

Look at all the error reporting paths
Remove OKResponse entirely, that isn't needed anymore since errors would be explicitly raised.

But we can move this to 3.1, yes

@ashb

@ashb do you think we should be working on this as part of 3.2 or move it to later with advances we have made in task sdk so far?

Moving to a different parent issue, we can figure out if this needs improvement there: #62061

Navigation Menu

Repository navigation

Improve error handling and logging in CommsDecoder interface #46426

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	except ServerResponseError as e:
	if e.response.status_code == HTTPStatus.NOT_FOUND:
	log.error(
	"XCom not found",
	dag_id=dag_id,
	run_id=run_id,
	task_id=task_id,
	key=key,
	map_index=map_index,
	detail=e.detail,
	status_code=e.response.status_code,
	)
	# Airflow 2.x just ignores the absence of an XCom and moves on with a return value of None
	# Hence returning with key as `key` and value as `None`, so that the message is sent back to task runner
	# and the default value of None in xcom_pull is used.
	return XComResponse(key=key, value=None)

Improve error handling and logging in CommsDecoder interface #46426

Description

Activity

kaxil commented on Apr 9, 2025

amoghrajesh commented on Jul 30, 2025

ashb commented on Jul 30, 2025

amoghrajesh commented on Feb 12, 2026

amoghrajesh commented on Feb 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions