Skip to content

InfluxDB3Operator: add deferrable variant #67107

Closed

Description

@arpitrathore

Description

The InfluxDB3Operator added in #58929 currently executes queries synchronously, which means each task holds an Airflow worker slot for the entire duration of the query. For long-running analytics or aggregation queries over InfluxDB 3 clusters, this prevents the worker from picking up other tasks while the query runs on the database.

This issue proposes adding a deferrable: bool = False parameter (and a separate trigger class) to InfluxDB3Operator, following the pattern already established in:

  • SnowflakeSqlApiOperator (deferrable variant with SnowflakeSqlApiTrigger)
  • BigQueryInsertJobOperator (deferrable mode with BigQueryInsertJobTrigger)
  • RedshiftDataOperator (deferrable with RedshiftDataTrigger)

Proposed API

from airflow.providers.influxdb.operators.influxdb3 import InfluxDB3Operator

InfluxDB3Operator(
    task_id="aggregate_metrics",
    sql="SELECT ... FROM measurement WHERE ...",
    influxdb3_conn_id="influxdb3_default",
    deferrable=True,
    poll_interval=30,
)

When deferrable=True, execute() should:

  1. Submit the query to InfluxDB 3 using InfluxDBClient3.query_async(), the asyncio coroutine exposed by influxdb3-python. (query_async was introduced in influxdb3-python 0.12.0; the influxdb provider currently declares influxdb3-python>=0.7.0, so the deferrable implementation will need to bump the lower bound to >=0.12.0.) For very large result sets, the synchronous query(mode="reader") Apache Arrow Flight stream is also available if a streaming result interface is preferred.
  2. Call self.defer(trigger=InfluxDB3QueryTrigger(...), method_name="execute_complete").
  3. The trigger polls the query state on the InfluxDB cluster at poll_interval and yields a TriggerEvent when the query finishes or fails.
  4. execute_complete() retrieves the result and pushes it to XCom in the same shape as the sync path.

Acceptance criteria

  • New deferrable: bool parameter on InfluxDB3Operator (default False for backward compatibility).
  • New InfluxDB3QueryTrigger (or similar) implementing the async polling loop using influxdb3-python's async client.
  • Unit tests covering both deferrable=True and deferrable=False code paths.
  • Integration test exercising the trigger end-to-end against a local InfluxDB 3 instance (or mocked equivalent if a real one is impractical in CI).
  • Provider documentation updated with a deferrable=True example.

Scope and tradeoffs

  1. InfluxDBClient3.query_async() is a loop.run_in_executor(None, ...) wrapper around the blocking Apache Arrow Flight calls (see influxdb3-python/influxdb_client_3/query/query_api.py). The interface is a proper coroutine and is suitable for use in a Trigger. Concurrency in the Triggerer is bounded by the executor's thread pool rather than by native async IO. Native async over Arrow Flight is a future improvement on the InfluxData client side, not a blocker for this issue. The provider's current influxdb3-python>=0.7.0 lower bound will need to be bumped to >=0.12.0, the release that introduced query_async.
  2. The deferrable variant frees a worker slot while the query runs, but the result still flows back through the operator and into XCom. This is most useful for long-running queries with small-to-moderate result sets (aggregations, freshness probes, dashboard queries). For very large extracts, the existing InfluxDB3Hook + Python task pattern remains the right answer, and this issue does not aim to replace it.

Use case/motivation

Analytics queries on InfluxDB Cloud Dedicated or InfluxDB 3 Enterprise routinely take minutes for windowed aggregations across high-cardinality measurements. In a constrained worker pool, holding a slot per long-running query limits the parallelism the rest of the DAG fleet can achieve. A deferrable variant releases the worker slot back to the pool the moment the query is submitted to InfluxDB. The Triggerer then polls the query state and resumes the task when the result is ready.

This matches established Airflow patterns and unblocks teams that want to standardise on the new InfluxDB3Operator without losing worker-slot efficiency.

Related issues

  • Original InfluxDB 3 support: Add support for influx3 in influxdb provider #58929
  • Snowflake deferrable reference: airflow/providers/snowflake/operators/snowflake.py, airflow/providers/snowflake/triggers/snowflake_trigger.py
  • BigQuery deferrable reference: airflow/providers/google/cloud/operators/bigquery.py, airflow/providers/google/cloud/triggers/bigquery.py

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Activity

  1. arpitrathore commented on May 21, 2026

    @arpitrathore
    ContributorAuthor

    I'd like to take this. Plan: add a deferrable parameter on InfluxDB3Operator and a new InfluxDB3QueryTrigger, modelled on the BigQuery and Snowflake deferrable patterns referenced above. Implementation will use InfluxDBClient3.query_async() (introduced in influxdb3-python 0.12.0), which will also require bumping the provider's lower bound from >=0.7.0 to >=0.12.0.

    Follow-up to my earlier PR #58929. Companion proposal to #67109.

    Happy to start once the issue is triaged. If a maintainer can take a quick look and assign it to me, I'll begin the PR.

  2. eladkal commented on Aug 21, 2026

    @eladkal
    Contributor

    Happy to start once the issue is triaged. If a maintainer can take a quick look and assign it to me, I'll begin the PR.

    Hey, we try to avoid assigning individuals as we found many times assigned people are not always delivering and with issue assigned there is less likelihood someone else will work on the issue (see policy)

    If you have a fix/feature implementation just raise PR directly. It is much easier to discuss over an actual code proposal.

  3. added and removed
    needs-triagelabel for new issues that we didn't triage yet
    on Aug 21, 2026
  4. codemouli commented on Aug 21, 2026

    @codemouli

    Hi, I am new to this and I would like to take this

  5. subhramit commented on Aug 22, 2026

    @subhramit
    Contributor

    Hi, I am new to this and I would like to take this

    Hey, since the project's policies state (and as also mentioned above) the convention to not expect assignment and directly work on issues, I had already started working on this over the last few days and will be filing a PR soon (expectedly today).

    Just so that your effort isn't duplicated, would you mind picking up something else or perhaps helping in review of this?

  6. codemouli commented on Aug 22, 2026

    @codemouli

    Sure No problem.

  7. subhramit commented on Aug 22, 2026

    @subhramit
    Contributor

    Filed #71976.
    Did not follow the exact API shape proposed here (the poll_interval doesn't apply, since InfluxDB 3's async query has no pollable job state to check). Have added more details in the PR description.

    cc @arpitrathore / @eladkal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions