dheerajturaga opened a new pull request, #75345: URL: https://github.com/apache/airflow/pull/75345
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. `BaseOperator.wait_for_webhook` (#75343) lets an operator park until a webhook delivery matches it, but a Dag author who only wants a task to wait for a delivery would still have to write that operator. This adds `WaitForWebhookOperator` to the standard provider: it registers a wait for the `events` and `match` it is given, parks in `awaiting_input` without a worker slot, a pool slot or a trigger, and returns the matching delivery as its XCom, so downstream tasks read its attributes and payload from there. - `webhook`, `events` and `match` are template fields, so a match can take a pull request number from an upstream task's XComArg, which also makes that task upstream of the wait, or from a Jinja template. - A wait that times out fails the task with a new `WebhookWaitTimeoutError`, a plain `Exception` subclass, instead of returning the timeout event as if it were a delivery. `execute_complete` tells the two apart by the timeout event's `error` key, which a delivery event never has. - A generic operator has nothing to poll, so there is no fallback: `WebhookWaitUnsupported` from an API server without webhook waits fails the task. - The module raises `AirflowOptionalProviderFeatureException` when the Task SDK's `BaseOperator` has no `wait_for_webhook`. It checks for the feature rather than `AIRFLOW_V_3_5_PLUS`, as the provider's webhook sources do, because a source build of main can still report the previous version; the tests skip the same way. The operator's page shows a GitHub merge gate and warns that the delivery's payload, as the webhook's `store_payload` keeps it, lands in XCom. It also says which deliveries that arrive before the wait are kept for it: only one with a correlation key that went to no other wait and recorded no topic or asset route events (#75342), so a wait registered later never gets a delivery that a Dag already received. This merges after #75343 and 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]
