dheerajturaga opened a new pull request, #75340: URL: https://github.com/apache/airflow/pull/75340
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. This adds the Execution API route that a task calls, with its own task token, to register a wait for a webhook delivery before it parks in `awaiting_input`. `POST /inbound-waits/{task_instance_id}` writes the wait to `inbound_wait` (#75339) and answers with its id, status and deadline. If a matching delivery arrived before the wait and was kept early, the route claims it, and the task resumes with it as soon as it parks. The route goes into the unreleased 2027-02-28 Execution API version, so a client on an older version gets a bare 404. Points to look at: - The route's 404s always carry a `reason`, such as `webhook_not_found`, so the Task SDK ({{PR-28}}) can tell them from the bare 404 of a server without the route. For the same reason a Dag with a team gets 403 `dag_has_team`, not a 404: webhooks serve only Dags without a team for now. That status is open to review. - A parked task's `execution_timeout` does not run, so the wait's deadline is the only thing that ends it. A wait without a timeout uses the new `[webhooks] default_wait_timeout`, which is unset by default, so such a wait is refused with 422. Timeouts are capped at 365 days because the deadline is a TIMESTAMP on MySQL. - The latest wait of a try wins. Within a webhook, an open wait's events and match belong to one task: a running or parked holder refuses the registration with 409 `wait_key_taken`, while the open wait of an attempt that can no longer resume, such as an earlier try, is ended so that the new wait takes the key, and a delivery with a correlation key that the ended wait had received is early again. - A registration and a delivery can each commit without seeing the other, so the route looks for early deliveries again after its own commit, and claims are compare-and-set on the delivery's outcome. Locks follow the order task instance, wait, delivery, which {{PR-27}} uses too. Because it commits before it looks again, the route opens its own sessions, as the webhooks delivery pipeline does; the helpers take a keyword-only session and never commit. A claim takes the oldest matching delivery received within the new `[webhooks] early_delivery_ttl`, gives it the new outcome `resumed_wait`, lists the wait under a new `waits` key of its `actions`, and writes an audit log entry for the task instance. Nothing keeps a delivery `early`, the other new outcome, until {{PR-27}}, which also uses the new `early_delivery_max_per_webhook`, so the tests here write early records directly. This is the first of the four PRs of the webhook waits unit, with {{PR-26}}, {{PR-27}} and {{PR-28}}. They merge together once all four are approved, so that no release can register a wait that nothing resumes. If they miss the 3.5 freeze, they move to 3.6 together and the route moves to a new Execution API version. --- ##### 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]
