Add bulk XCom deletion to Execution API

[justinpakzad]

This PR implements bulk XCom deletion functionality. The issue was that it's not possible to delete all XComs for a dag run using the XCom.delete() method since task_id and key are required arguments. Given there is no direct database access, adding bulk deletion functionality would allow users to run clean up tasks at the end of their Dags, which can help prevent db bloat when the Xcoms don't really have much archival value.

I added a new bulk_delete_xcoms() endpoint to the execution API with task_id and key as optional query parameters. This allows a user to just pass in dag_id and run_id to delete all XComs associated with that run.

A delete_all() method was added to the BaseXCom class as well as the associated method in the client which calls the execution API. New message type was added to the supervisor and trigger job runner.

I created tests to cover the different deletion patterns: deleting all XComs for a run, deleting all keys for a specific task, and deleting a specific key across all tasks. Cadwyn migration file was also updated with the new change.

closes: #57812

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[justinpakzad]

Just following up here - I implemented the suggestions about the XCom.delete() parameters. Let me know if the approach looks sound.

[uranusjr]

This will need a migration to move existing calls to the new endpoint (since the path has changed).

[justinpakzad]

Updated the has_xcom_access func to make task_id and key optional as suggested. Doing so allows the router level dependency to be compatible with the bulk endpoint.

[justinpakzad]

@amoghrajesh, not usually one to tag but I couldn't re-request review. Do you mind taking a look at the updates whenever you have a chance. Thanks.

[potiuk]

Please rebase. You have conflicts.

[justinpakzad]

Apologies for the delay, last few comments, looking much better now

Thanks for the review! Addressed all the comments. The bulk delete endpoint now returns the count of deleted rows instead of the generic message. The client then returns a XComDeleteCountResponse. Fixed the dup test_id and added another test in the supervisor for the map_index.

[justinpakzad]

@amoghrajesh Can you give this another review when you have a chance? Addressed all of your most recent comments. Thanks.

[potiuk]

@amoghrajesh — @justinpakzad addressed your feedback on this PR back in May (most recent push: 2026-05-14) and the CHANGES_REQUESTED state has now been blocking the PR for ~5 months. Could you either re-review and dismiss / re-approve, or explicitly dismiss the request-changes if your concerns are addressed?

@eladkal mentioned earlier we wanted this in 3.2.0 — happy to have someone else take a look if you don't have bandwidth, just let us know.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes.

---

Drafted-by: Claude Code (Opus 4.7); reviewed by @potiuk before posting

[justinpakzad]

@amoghrajesh do you mind giving this another review? Would love to get this merged. I addressed all of your previous comments and I also made updates to follow the new request_handlers pattern, so that it's aligned with all the rest. Thanks.

[potiuk]

@justinpakzad — Changes have been requested on this PR, so I've removed the ready for maintainer review label — the next step is on your side. Could you address the review comments (push a fix, or reply in-thread explaining why the feedback doesn't apply)? Once addressed, re-mark the PR ready and it returns to the maintainer queue. Thank you.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[justinpakzad]

@justinpakzad — Changes have been requested on this PR, so I've removed the ready for maintainer review label — the next step is on your side. Could you address the review comments (push a fix, or reply in-thread explaining why the feedback doesn't apply)? Once addressed, re-mark the PR ready and it returns to the maintainer queue. Thank you.

@potiuk The changes requested had been addressed quite a while ago and I have consistently pushed fixes for all other review comments. Been awaiting for another review on this. Would appreciate if this was added back to the maintainer queue.

[jroachgolf84]

cc: @ashb

[justinpakzad]

Would really appreciate another review on this.

[justinpakzad]

@ashb would you mind giving this a review when you have a moment?