Page History

...

Attendees

Summary

• Note: Vikram was traveling and asked Ash Berlin-Taylor to lead the call on his behalf.

• Catch-up on action items from last call
  • None
• Airflow 3.2 Development Updates
  • Testing / Release Manager Update (Rahul Vats)
    • Rahul gave a 3.2 release and testing update. The current target is to cut RC1 on Monday, March 30th.
    • Beta 2 has already been cut and testing is actively in progress. From this point onwards, Rahul will be cherry-picking bug fixes and other items tagged with the 3.2.0 milestone, rather than fast-forwarding with main. The cherry-pick strategy was shared on the dev list.
    • Migration testing is now in good shape. The blockers raised on the last call around migration performance have been resolved with community help, and the migration scripts have been tested across all three supported databases with no remaining issues.
    • Regression testing for the SDK and other areas is looking clean, and there are currently no critical or high priority issues. UI sanity testing is still in progress with a few medium priority bugs identified, but none are considered RC blockers.
    • Rahul specifically called out AIP-76 Asset Partitions as being in good shape, with solid testing done by Atul. Deadline Alerts owners were asked to update the test plan status, as the current one appeared to be a reuse from the 3.1 async work. Multi-team testing looks mostly complete with one open issue remaining.
    • Ash noted that 3.2 is now effectively in feature freeze — no new features will be added, and anything not already in will need to wait for 3.2.1 or 3.3.
    • Community was asked to test Beta 2 and report any high or critical priority issues on the dev list or Slack, using the beta label for tracking.
  • UI / API swim lane update (Pierre Jeambrun)
    • Pierre reported that the team has been focused on bug fixes and improvements targeted for 3.2.
    • Good progress has been made on the optimization front, with improvements to the dashboard page, DAG run listings, DAG listings, and log streaming. These will ship in 3.2, though more optimization work remains.
  • Deadline Alerts (Dennis Ferruzzi)
    • Dennis shared a detailed update in Slack the night before the call.
    • There is a PR currently open and under active review. Ash, Amogh, and Kaxil had all provided feedback. Dennis is working through Ash's design comments and expects to have a proposal within the hour.
    • All remaining work — including wiring for get connection, get variable, get asset, get XCom — is done locally and ready to be submitted within an hour of the blocking PR being merged.
    • Anish is working on a PR to unify workload handling, which is largely complete but will need a small refactor once the blocking PR lands.
    • Every executor needs to be updated, and volunteers have been assigned for each, with most having draft PRs already open.
    • Given the timing, the team agreed that the connection access piece is likely to land in 3.2.1 rather than 3.2, which can reasonably be treated as a bug fix.
  • Multi-team (Niko Oliveira)
    • UAT was largely completed last week, with just one remaining open issue related to CI.
    • All features scoped for 3.2 are in, and the team is holding off on any new development to avoid unintentional merges into the 3.2 branch.
    • Phase 2 development targeting 3.3 will start soon. Ash noted that by default nothing will get merged into 3.2 without an explicit request, so the team can start development without risk of accidentally landing 3.3 work in 3.2.
  • Python Async Operator docs (David Blain)
    • David was not on the call. Deferred to next call.
• Discussion Topics
  • AIP-99 Progress and Demo (Pavan Kumar)
    • Pavan gave a live demo of AIP-99, the Common Data Access Patterns + AI work, which generated a lot of enthusiasm from the team.
    • For those unfamiliar, AIP-99 uses a Pythonic AI framework under the hood to enable unified, AI-assisted access to different data sources via existing Airflow hooks. The goal is to allow agents to connect to any database or data source Airflow supports, in a consistent way.
    • The demo covered two example DAGs. The first was a data analyst agent using a SQL toolset connected to a Postgres database with Human-in-the-loop (HITL) review enabled. The agent fetched data, responded to natural language queries, and paused for human input before proceeding — all within the task instance UI. The current implementation runs on a worker with XCom as the backend for agent/human communication.
    • The second demo showed a file analysis agent, using the Airflow Object Store interface to read a sample image and return a structured analysis of its key components.
    • Amogh suggested that when HITL review is active, there should be a clearer visual indicator in the UI so users know the task is waiting on their input.
    • Ash and Daniel noted that the experience feels conceptually different from a typical DAG run, though agreed that naming this distinction is hard enough that leaving it as-is for now is reasonable.
    • Pavan noted the work is approaching a 0.1 release, planned for the following week, and that recorded demos will be shared.
    • Shubham expressed excitement about the demo and the potential use cases.
  • Time based, scope-restricted Personal Access Tokens / PATs (Dheeraj Turaga)
    • Dheeraj raised the challenge that users are currently generating JWT tokens and passing them to LLMs to interact with Airflow programmatically, but those tokens are short-lived. The ask is for longer-lived tokens with admin-level controls — including the ability to revoke tokens and to scope them to read-only or limited permissions, to prevent LLMs from taking unintended write actions in production.
    • Ash noted that this is a meaningful ask but complicated by the Auth Manager architecture, where each auth manager has its own mechanisms and token lifecycle handling would likely need to be implemented per auth manager.
    • Karthikeyan highlighted the specific challenge of a user wanting read/write access for UI interactions but read-only access for LLM interactions — something tokens don't currently capture. He also shared a link to an existing token invalidation issue (#47952) and a related Claude Code issue around token refresh.
    • Jarek noted that token revocation has recently been added (PR #61339 merged by Pierre), and that token refresh is already possible while a token is valid. He suggested that an agent could potentially be instructed to refresh its token, though Ash noted this doesn't address the case where a token has fully expired.
    • Bugra suggested separating the concerns of token lifetime extension and token revocation, as they interact with different layers — token lifetime is tied to the auth manager, while revocation may be interceptable at the base auth manager level.
    • The general consensus was that this is a valid and important ask that requires deliberate design, particularly around security and scope controls. Jarek noted this is part of why he had reservations about MCP support — these security design questions need to be thought through carefully.
    • Dheeraj agreed to start an async discussion on the dev list to continue the conversation.
  • DualStatus Manager backwards compatibility (Christos Bisias)
    • This was an unplanned topic raised by Christos. A lazy consensus vote on the dev list to remove the DualStats Manager interface passed last Saturday, and Christos is working on a PR to remove it.
    • The question was whether it could be removed now given that it appeared in a recent provider release.
    • Ash clarified that since provider code referencing the DualStats Manager has already been released on PyPI, the import cannot be removed until those provider versions are no longer supported — roughly when the minimum provider version reaches Airflow 3.3, which is approximately 3 minor versions away.
    • The implementation can be changed (e.g. aliased to the new Stats Manager or made a no-op), but the import path must remain intact to avoid breaking released code.
    • Ash suggested Christos check whether the existing provider usages are wrapped in a try/except ImportError — if so, removal may be possible sooner. If they rely on a version check instead, the import must stay.
    • Daniel suggested that aliasing DualStats Manager to Stats Manager would be the simplest path forward, since the underlying behavior has already been moved.
    • Ash closed by reminding everyone to test Beta 2, with RC1 targeted for Monday. He also noted that 3.3 is planned to be a shorter cycle of roughly 3 months.

...

Attendees

Summary

• Vikram opened the retrospective noting that spring break and general post-release fatigue meant a lighter attendance than usual.
• Catch-up on action items from last call
  • None
• Airflow 3.2 Retrospective
  • Release Manager perspective (Rahul Vats)
    • Rahul opened by thanking all contributors who helped with development and testing for 3.2.
    • Rahul proposed introducing a recognition program for community members who file bugs during beta and RC phases, similar in spirit to the existing "PR of the Month," to incentivize earlier and broader community testing.
    • Jarek noted that the model used for provider releases works well: a GitHub issue is created that tags contributors and explicitly asks them to test the specific things they contributed. He suggested adapting this for minor releases, with a more compact version of the issue given the larger scope. He noted that for the most recent provider release, around 80% of tagged contributors confirmed they had tested their changes. Jarek also suggested reaching out directly to users who had filed issues that were fixed in the release, asking them to test the beta or RC on their staging environments — since those users are already motivated to see their fix land.
    • Jens highlighted that the key gap is getting testing done in production-like environments rather than artificial small-scale setups, since many issues only surface at real scale. He suggested building a more comprehensive integration test suite that covers known corner cases and can run longer, more complex scenarios.
    • Rahul agreed and noted that a few issues during RC1 were related to object storage on cloud — scenarios that exist in the E2E test suite but weren't being run against real cloud environments. He suggested reviewing gaps in E2E coverage as a follow-up.
    • Jens also noted that the Easter break timing reduced available testing resources significantly, and suggested that having an additional beta before cutting the RC, combined with targeted contributor outreach, would give the community more time to catch issues earlier.
  • Documentation-first proposal (Elad Kalif)
    • Elad raised two observations. First, that a large number of non-feature commits and bug fixes are bundled into minor releases, adding risk. He suggested considering whether some of those could go into a separate minor release to reduce scope.
    • Second, and more significantly, Elad noted that documentation for major features was arriving very late in the cycle, often close to the beta cut, making it very difficult to test features effectively. He proposed requiring that documentation be written upfront, even before implementation in some cases, so that testers can understand the intended behavior and verify against it.
    • Vikram said he was a strong fan of this idea, noting that with AI tools it is now very easy to generate and maintain documentation concurrently with code, and therefore there is little excuse for late docs. He suggested this should be a prerequisite for a feature being merged or included in the first beta, at least for significant features.
    • Jarek agreed and added that he has used an AI agent to continuously update documentation while developing, which works very well and can even generate screenshots. He noted this represents a shift in development mindset but is very achievable.
    • Rahul noted this would also reduce the last-minute documentation rush before RCs.
    • Action item: Elad to write up the proposal for requiring documentation alongside significant feature development as a prerequisite for beta inclusion, to be shared on the dev list.
  • Security landscape update (Jarek Potiuk)
    • Jarek shared a broader update on the security landscape that had affected the 3.2 release process.
    • A supply chain security incident occurred in recent weeks involving LiteLLM, where maintainers were impersonated. The Google provider had a dependency on LiteLLM and was briefly affected. The vulnerable version was pulled from PyPI within about two hours. 
    • Separately, Jarek shared that Anthropic is investing $1.5M into ASF security initiatives, with $250K from Alpha Omega as a seed, as part of a new ASF Responsible AI initiative announced the day before the call. The goal is to raise $3M this year and $10M overall to fund tooling and access to advanced AI security models. He explained that the emerging security model involves AI that can proactively find and generate patches for security vulnerabilities, turning the security process from reactive to proactive. Bug bounty programs have already been suspended by several organizations as AI can now find vulnerabilities faster than human researchers.
    • ASF will receive early access to Anthropic models currently under embargo. The details of how access will be distributed are still being worked out at the ASF board level, with a decision expected at the board meeting in about a week and a half. A VP of AI Tooling role is expected to be appointed to lead the initiative.
    • Dheeraj asked whether ASF maintainers would receive direct access to Anthropic's preview models. Jarek confirmed that access is being arranged, either directly from Anthropic or through Alpha Omega, though it will be limited to those involved in security work due to embargo constraints.
    • Vikram noted that Airflow's cooldown protection is now in place broadly and asked the team to keep an eye on further developments.
  • UI / API feedback (Brent Bovenzi)
    • Brent noted that the increased PR velocity from the community on UI has been a mixed experience, helpful for getting features like additional filters and search shipped, but requiring more effort to reject low-quality PRs. He and Pierre have had to be stricter in their review standards.
    • Brent also noted that the pace of feature work has sometimes meant less time for thoughtful UX design.
  • Jens's upgrade issue follow-up
    • Vikram asked Jens about the GitHub issues he had planned to file from the Bosch upgrade experience. Jens said he had filed the easy ones and some had already been fixed in parallel, but had not completed the full list due to work pressures.
• Discussion Topics:
  • AIP-103 Task State Management (Vikram)
    • Vikram noted he is looking forward to working with XD and Jake on AIP-103 Task State Management, with a target of the 3.3 release. He thanked everyone who gave feedback and voted on this.
    • Jake is also working on an updated incarnation of the Asset Watermarking AIP, rebasing it on the Task State Management work.
    • Vikram noted he plans to clean up the related Confluence pages, as there are currently around 4 to 5 related AIPs that are not well organized. The goal is to track them as a cohesive epic rather than unrelated items.
  • AIP-72 Multi-language support / Java Task SDK update (Vikram)
    • Vikram noted that TP has been making significant progress on the Java Task SDK, which represents the first delivery of non-Python multi-language support for the Task SDK.
    • It felt too rushed to include in 3.2, but Vikram has scheduled a demo for the next dev call in two weeks. He wanted to make sure the community was aware of this work, as it had not been discussed broadly as a group.
  • AIP-94 CLI Decoupling update (Bugra Ozturk)
    • Bugra shared that now that 3.2 is released, he has started creating tickets for AIP-94 (decoupling the CLI using Airflow CTL), all with the 3.3 milestone. He flagged this for awareness and asked the community to keep an eye out for new issues being created.
    • Vikram thanked Bugra and said he would update the wiki page in the next couple of days to reflect this.

...

...