dheerajturaga opened a new pull request, #75035:
URL: https://github.com/apache/airflow/pull/75035

   ### Stack
   
   Stacks on #75034. Stack index: 3 of 20.
   
   A PR from a fork cannot target a fork branch, so each PR in the stack is 
based on `main` and contains every commit below it; only the top commit is new. 
Review only the commit "AIP-125: Add inbound_delivery table"; the commits below 
it belong to earlier PRs in the stack.
   
   ### Status
   
   Draft. [AIP-125 (Inbound 
Webhooks)](https://lists.apache.org/thread/p3dpnor4zwko8tldpncj6ftj1bpp18q7) is 
under discussion on dev@ and not yet voted; this stack is its proof of concept 
so that voters can run it, and nothing should merge before the vote. The 
feature is opt-in (only `airflow api-server --apps webhooks` serves deliveries) 
and experimental; no unauthenticated route is reachable until stack PR 18, 
which merges last.
   
   ### Why
   
   AIP-125 records every verified inbound webhook delivery in the metadata 
database, so that a sender's retry is recognised and the deliveries view and 
topic events can point back at what arrived. Landing the schema on its own 
keeps the migration reviewable before any code writes to the table; nothing 
writes to it here.
   
   ### What to look at
   
   - The dedupe key: unique `(webhook, delivery_id, body_digest)`. Deliveries 
without an id never collide, since NULLs are distinct.
   - `airflow db clean` ages rows by `retain_until` (`received_at` plus 
`[webhooks] delivery_retention`) rather than by receipt time, so each row keeps 
the retention configured when it arrived, whatever the cutoff.
   - Columns for later: `attributes` and the `correlation_key` index serve 
Phase 2; `team_name` has no foreign key, as for `Log.team_name`, and stays NULL 
while 3.5 is teamless.
   - `webhook` is `StringID(64)` and `delivery_id` is `StringID(255)`; the 
migration is stamped `3.5.0` by hand.
   
   ### Testing
   
   - `test_inbound_delivery.py`, `test_db_cleanup.py` and the migration 
stairway test passed under breeze on SQLite, Postgres and MySQL.
   - The migration round-trip check passed; `update-migration-references` 
regenerated `migrations-ref.rst` under breeze.
   
   ### Known limitations
   
   - Phase 2's `inbound_wait` table is not part of this migration.
   
   ---
   
   ##### 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]

Reply via email to