Skip to content

Cap the workers of the SFTP concurrent directory transfer test - #74888

Merged
shahar1 merged 1 commit into
apache:mainfrom
shahar1:ci-sftp-test-cap-workers
Oct 16, 2026
Merged

shahar1 merged 1 commit into
apache:mainfrom
shahar1:ci-sftp-test-cap-workers

Conversation

@shahar1

@shahar1 shahar1 commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

related: #74889

As titled, required to avoid failures of test_store_and_retrieve_directory_concurrently when there's a large number of CPUs or throttled ones.

AI Summary `test_store_and_retrieve_directory_concurrently` lets the hook pick its default worker count, `os.cpu_count()`. Each worker opens its own SSH connection, one after another, before any transfer starts, so the test's runtime grows with the host's CPU count.
  • Where it broke: on the self-hosted EKS runners of an earlier CI experiment, os.cpu_count() reported 32–48 (it ignores cgroup CPU limits). The test hit the 60s per-test timeout in 14 jobs, including on a dedicated node.
  • Local timing: 64 workers take 24s for their 128 sequential handshakes, so slower or throttled hosts cross the limit.
  • Not sshd: MaxStartups is not involved. The connections authenticate one at a time, and 32 and 64 workers both pass against its default.

Passing workers=4 keeps the test doing exactly what it does on today's 4-vCPU GitHub-hosted runners, whatever the host. The change is test-only and leaves the hook's default alone. It is a prerequisite for running CI on larger runners (see the RunsOn experiment in #74714).

Checks run locally: ruff format, ruff check and the prek pre-commit hooks on the changed file. CI on this PR runs on GitHub-hosted runners.


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

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


  • Read the 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) is needed.
  • When adding dependency, check compliance with the ASF 3rd Party License Policy.
  • For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

`store_directory_concurrently` and `retrieve_directory_concurrently`
default to `os.cpu_count()` workers, and each worker opens its own SSH
connection, one after another, before any transfer starts. The test's
runtime therefore grows with the host's CPU count. On the self-hosted
EKS runners of an earlier CI experiment `os.cpu_count()` reported 32-48
(it ignores cgroup CPU limits) and the test hit the 60s per-test timeout
in 14 jobs, including on a dedicated node. Locally, 64 workers take 24s
for their 128 sequential handshakes, so slower or throttled hosts cross
the limit. The 32-vCPU class of the RunsOn runners (apache#74714) has the same
exposure.

sshd's `MaxStartups` is not involved: the connections authenticate one
at a time, and 32 and 64 workers both pass locally against its default.

Four workers is what the test uses on today's 4-vCPU GitHub-hosted
runners, so it keeps exercising the same path whatever the host.
@shahar1
shahar1 merged commit f54d32d into apache:main Oct 16, 2026
162 checks passed
@shahar1
shahar1 deleted the ci-sftp-test-cap-workers branch October 16, 2026 20:50
SameerMesiah97 pushed a commit to SameerMesiah97/airflow-oss-sm97 that referenced this pull request Oct 27, 2026
…e#74888)

`store_directory_concurrently` and `retrieve_directory_concurrently`
default to `os.cpu_count()` workers, and each worker opens its own SSH
connection, one after another, before any transfer starts. The test's
runtime therefore grows with the host's CPU count. On the self-hosted
EKS runners of an earlier CI experiment `os.cpu_count()` reported 32-48
(it ignores cgroup CPU limits) and the test hit the 60s per-test timeout
in 14 jobs, including on a dedicated node. Locally, 64 workers take 24s
for their 128 sequential handshakes, so slower or throttled hosts cross
the limit. The 32-vCPU class of the RunsOn runners (apache#74714) has the same
exposure.

sshd's `MaxStartups` is not involved: the connections authenticate one
at a time, and 32 and 64 workers both pass locally against its default.

Four workers is what the test uses on today's 4-vCPU GitHub-hosted
runners, so it keeps exercising the same path whatever the host.
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.

2 participants