Repository navigation
Conversation
20d6bd9 to
8c53810
Compare
57f338e to
fcc393a
Compare
fcc393a to
bd8e7ec
Compare
bd8e7ec to
e87f0ba
Compare
e87f0ba to
7d568c9
Compare
ab413e1 to
c822f45
Compare
aa82a98 to
0de4133
Compare
0de4133 to
4a545fd
Compare
Signed-off-by: 1fanwang <[email protected]>
Signed-off-by: 1fanwang <[email protected]>
e08f021 to
77b67ad
Compare
|
Hello @1fanwang - thank you for your contributions to Apache Airflow! The Airflow community has introduced a limit of 5 open pull requests at a time for contributors without write access to the repository. You currently have 34 open pull requests, so - as a one-time step of introducing the limit - we closed the ones where maintainers have not engaged yet:
These pull requests stay open because maintainers are already engaged in them - they count towards your limit:
This is not a judgement of you or of your changes. We never told contributors before that opening many pull requests at once was a problem, so there is nothing to feel bad about - and nothing is lost: your branches, commits and the review history stay where they are. What we ask you to do is to make your first prioritization decision: choose which of the pull requests above matter most to you, and reopen them (up to 5 open at a time, including the ones still open) with the "Reopen pull request" button or While your pull requests are waiting for review, the most valuable thing you can do is help in other ways - reviewing other contributors' pull requests, helping with issues, and taking part in the discussions on the devlist and Slack. Why we introduced the limit, what it means for you and how to reopen or restore a pull request is explained in https://github.com/apache/airflow/blob/main/contributing-docs/32_open_pull_request_limit.rst. Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting |
An infrastructure interruption can stop healthy task code and consume an ordinary retry. This combined prototype reports failure causes to listeners and metrics, and lets administrators grant bounded replacement attempts for confirmed infrastructure failures.
[core] max_infra_retriesdefaults to0; Dag authors get no new parameter. The policy reuses existing retry fields without a migration or an AIP-103 counter. Ordinary attempts and clears can exhaust the allowance early. Raising ordinary retries can reopen an early refusal, but not once the prior-attempt count reaches the cap. Unclassified failures do not qualify.This implements the combined reference for AIP-97 classification and AIP-116 bounded infrastructure retries. Classification is independently reviewable in #73350.
Testing Done
Real Kubernetes Task SDK workers made authenticated starts and later heartbeats before interruption. PostgreSQL snapshots, listener records, callbacks, and UDP metrics showed:
retries=0retry,success,successThe runnable workflow, complete fixture, provenance, and sanitized evidence include setup. These commands ran on Linux:
Raw runtime observations
The receipt identifies the exact candidate SHA used by the runtime processes. The selected lines above are unchanged; workspace-normalized linked output is labeled sanitized.
The run used kind and PostgreSQL. It observed forced termination under a 30-second grace configuration, not cooperative SIGTERM completion, and did not exercise Celery or AWS.
Was generative AI tooling used to co-author this PR?
Generated-by: GitHub Copilot CLI 1.0.80 (GPT-5.6 Sol) following the guidelines
{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.