dheerajturaga opened a new pull request, #75346: URL: https://github.com/apache/airflow/pull/75346
Part of [AIP-125 (Inbound Webhooks)](https://lists.apache.org/thread/p3dpnor4zwko8tldpncj6ftj1bpp18q7), which lets external services such as GitHub trigger Dags by sending webhooks to Airflow. `WaitForWebhookOperator` (#75345) takes its match as a template field, which can place an upstream task's result in it but not compute anything from it, so a Dag that picks the match's keys or values from what an upstream task returned needs one more task. With `@task.webhook_wait`, the decorated function builds the match from its arguments, which can be XComArgs and Jinja templates, and returns it. The task then waits as the operator does and returns the matching delivery as its XCom: ```python @task.webhook_wait(webhook="github", events=["pull_request"], timeout=timedelta(days=3)) def wait_for_merge(number: int) -> dict: return {"repository": "my-org/configs", "number": number, "action": "closed"} ``` - The function runs on the worker once in each try, before the wait is registered, and never on resume. A return value that is not a dict fails the task with `TypeError` before any wait is registered. - A `match` argument is refused with `TypeError`: the task would otherwise ignore it and wait on the function's match alone, which can be wider than the author meant. - `multiple_outputs` is always `False`. A `dict` return annotation describes the match, and inferring multiple outputs from it would split the delivery into one XCom per key. - The decorator is registered in the standard provider's `task-decorators` and typed in the Task SDK's `decorators/__init__.pyi`, the one Task SDK file this touches. Its module imports the operator's, so it is refused the same way on an Airflow without webhook waits. The AIP draft lists a TaskFlow form of the wait API among its non-goals; this decorator reverses that, and the AIP is being updated to match. The operator's page now describes the decorator and shows the merge gate in both forms. This merges after #75345 and, like it, is released in a standard provider wave after the 3.5.0 Task SDK. --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 5.5) Generated-by: Claude Code (Opus 5.5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) --- * Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information. Note: commit author/co-author name and email in commits become permanently public when merged. * For fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed. * When adding dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x). * For significant user-facing changes create newsfragment: `{pr_number}.significant.rst`, in [airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments). You can add this file in a follow-up commit after the PR is created so you know the PR number. -- 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]
