Skip to content

Make test_cli_run_time tolerant of slow/cold CI runners - #68968

Merged
potiuk merged 1 commit into
apache:mainfrom
potiuk:harden-flaky-cli-time-and-provider-scan-tests
Jun 26, 2026
Merged

Make test_cli_run_time tolerant of slow/cold CI runners#68968
potiuk merged 1 commit into
apache:mainfrom
potiuk:harden-flaky-cli-time-and-provider-scan-tests

Conversation

@potiuk

@potiukpotiuk commented Jun 25, 2026

Copy link
Copy Markdown
Member

test_cli_run_time asserted the best of 3airflow --help startup samples was under a tight 5s bound. On a loaded or cold runner — e.g. the Pendulum2 special-test job (Tests (AMD), v3-3-test), which runs in a freshly rebuilt env — the whole-provider-load startup consistently sits just over it (best of 3 was 5.49s), even though nothing regressed.

Take the min of 5 samples and loosen the threshold to 8s, so the test still guards against gross startup regressions without flaking on small fluctuations.

The tableau-import root cause behind the same run's ProvidersManager timeout is handled separately in #68971 (lazy-import).

Should be backported to v3-3-test.


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

Generated-by: Claude Code (Opus 4.8) following the guidelines

@potiuk
potiukforce-pushed the harden-flaky-cli-time-and-provider-scan-tests branch from 70fa63f to 94b7396CompareJune 25, 2026 07:56
The test asserted the best of 3 "airflow --help" startup samples was under a
tight 5s bound. On a loaded or cold runner (e.g. the Pendulum2 special-test job,
which runs in a freshly rebuilt env) the whole-provider-load startup consistently
sits just over it -- the best of 3 was 5.49s -- even though nothing regressed.
Take the min of more samples and loosen the threshold so the test still guards
against gross startup regressions without flaking on small fluctuations.
@potiuk
potiukforce-pushed the harden-flaky-cli-time-and-provider-scan-tests branch from 94b7396 to 3065b80CompareJune 25, 2026 08:14
@potiukpotiuk changed the title Harden two timing-sensitive special-test failures on slow CI runnersMake test_cli_run_time tolerant of slow/cold CI runnersJun 25, 2026
@potiukpotiuk added the backport-to-v3-3-test Backport to v3-3-test label Jun 26, 2026
@potiuk
potiuk merged commit b24194f into apache:mainJun 26, 2026
71 checks passed
@potiuk
potiuk deleted the harden-flaky-cli-time-and-provider-scan-tests branch June 26, 2026 18:49
@github-actionsgithub-actionsBot added this to the Airflow 3.3.1 milestone Jun 26, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.3.1 based on: backport label targeting v3-3-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

@github-actions

Copy link
Copy Markdown
Contributor

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

StatusBranchResult
v3-3-testPR Link

potiuk added a commit that referenced this pull request Jun 26, 2026
…68968) (#69053)
The test asserted the best of 3 "airflow --help" startup samples was under a
tight 5s bound. On a loaded or cold runner (e.g. the Pendulum2 special-test job,
which runs in a freshly rebuilt env) the whole-provider-load startup consistently
sits just over it -- the best of 3 was 5.49s -- even though nothing regressed.
Take the min of more samples and loosen the threshold so the test still guards
against gross startup regressions without flaking on small fluctuations.
(cherry picked from commit b24194f)
Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
karenbraganz pushed a commit to karenbraganz/airflow that referenced this pull request Jun 30, 2026
The test asserted the best of 3 "airflow --help" startup samples was under a
tight 5s bound. On a loaded or cold runner (e.g. the Pendulum2 special-test job,
which runs in a freshly rebuilt env) the whole-provider-load startup consistently
sits just over it -- the best of 3 was 5.49s -- even though nothing regressed.
Take the min of more samples and loosen the threshold so the test still guards
against gross startup regressions without flaking on small fluctuations.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:CLIbackport-to-v3-3-testBackport to v3-3-test

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@potiuk@bugraoz93