Skip to content

Add deferrable mode to QuickSight operator and sensor - #70218

Open
ozemin wants to merge 3 commits into
apache:mainfrom
ozemin:quicksight-deferrable
Open

Add deferrable mode to QuickSight operator and sensor#70218
ozemin wants to merge 3 commits into
apache:mainfrom
ozemin:quicksight-deferrable

Conversation

@ozemin

@ozemin ozemin commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Adds deferrable=True support to QuickSightCreateIngestionOperator and QuickSightSensor, following the same waiter-based pattern as the rest of the Amazon provider. QuickSight has no official boto3 waiters (boto/boto3#2769), so this adds a custom ingestion_complete waiter and a QuickSightIngestionCompletedTrigger, and replaces the hook's hand-written polling loop, which held a worker slot with time.sleep and had no upper bound.

One thing without a direct precedent: DescribeIngestion requires AwsAccountId, so it is resolved on the worker before deferring and passed to the trigger — the triggerer never makes a sync STS call.

Behaviour changes: the synchronous wait is now bounded by waiter_max_attempts (default 60 attempts × 30s) instead of waiting forever; noted in the provider changelog. QuickSightHook.wait_for_state and the operator's check_interval are deprecated (still working) in favour of wait_for_ingestion / waiter_delay. Failures raise QuickSightIngestionFailedError, an AirflowException subclass.


Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code

@o-nikolas o-nikolas left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there are conflicts and build failures that need looking at. Also, I'm not sure of the breaking change (the new 30min timeout). I think large ingestions will easily pass that and fail dags for folks using this operator. We could make the default much higher, or go through a deprecation process where we log that the user should switch to setting a high default before we remove it. Or wait until a major release for the amazon provider package.

Curious what @vincbeck and @ferruzzi think

Comment thread providers/amazon/docs/changelog.rst Outdated
Comment thread providers/amazon/src/airflow/providers/amazon/aws/hooks/quicksight.py Outdated
**kwargs,
):
super().__init__(**kwargs)
if check_interval is not None:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of weird, you set a default value and then you check whether a value is assigned to it. In other words, anyone using this operator without setting check_interval will get a deprecation warning. I would leave the default value to None and keep following the deprecation warning process

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default is None, so the warning only fires when check_interval is passed
explicitly. It's a few lines above the context collapsed here:

check_interval: int | None = None,
deferrable: bool = conf.getboolean("operators", "default_deferrable", fallback=False),
**kwargs,
):
super().__init__(**kwargs)
if check_interval is not None:
warnings.warn(
"The `check_interval` parameter is deprecated and will be removed in a future release. "
"Use `waiter_delay` instead. While `check_interval` is set, it takes precedence over "
"`waiter_delay`.",
AirflowProviderDeprecationWarning,
stacklevel=2,
)

Happy to change it if you meant something else.

@ozemin

ozemin commented Jul 27, 2026

Copy link
Copy Markdown
Contributor Author

We could make the default much higher

Raised the default wait to 36 hours: 4320 attempts at the 30s delay, or 2160 at the sensor's 60s poke interval. That's how long AWS itself waits on a SPICE ingestion in the CloudFormation wait policy, where 36 hours is both the default and the maximum:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-quicksight-dataset-ingestionwaitpolicy.html

ozemin added 3 commits July 27, 2026 22:19
The QuickSight create-ingestion wait path used a hand-written polling
loop that held a worker slot with time.sleep and had no upper bound, so
a stuck ingestion could block a worker indefinitely. Moving the wait to
a custom boto waiter lets both the operator and the sensor defer to the
triggerer with deferrable=True, matching the deferrable pattern used
across the Amazon provider, and bounds the synchronous wait as well.
AWS waits up to 36 hours for a SPICE ingestion in its own CloudFormation
wait policy, where 36 hours is both the default and the maximum.
Refreshes that run for several hours are common, so a shorter cap fails
Dags that previously waited without a limit.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-quicksight-dataset-ingestionwaitpolicy.html
@ozemin
ozemin force-pushed the quicksight-deferrable branch from ca7307e to 5e254c3 Compare July 27, 2026 19:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants