Skip to content

Fix scheduler crash when the API server response is a redirect - #71962

Closed
ColtenOuO wants to merge 1 commit into
apache:mainfrom
ColtenOuO:fix-scheduler-crash-on-3xx-redirect
Closed

ColtenOuO wants to merge 1 commit into
apache:mainfrom
ColtenOuO:fix-scheduler-crash-on-3xx-redirect

Conversation

@ColtenOuO

Copy link
Copy Markdown
Contributor

closes: #49099

Summary

get_json_error() only wraps 400-599 responses in the picklable ServerResponseError -- it needs a custom __reduce__ because a plain httpx.HTTPStatusError requires keyword-only request/response arguments that pickle's default reconstruction can't supply (see #47873, fixed for that path by #48517).

A 3xx response -- e.g. a corporate proxy in front of the API server returning a redirect -- falls outside that range, so
httpx.Response.raise_for_status() raises the bare, unpicklable httpx.HTTPStatusError instead. That crashes the scheduler once the exception crosses a multiprocessing boundary: LocalExecutor.result_queue is a multiprocessing.Queue, and unpickling the exception on the scheduler side fails with the exact "missing keyword-only arguments" TypeError #47873 first reported -- just triggered by a redirect instead of a JSON error body.

Reproduced and confirmed with a standalone script -- the same failure mode as #47873's crash log.

Change

Added _raise_for_status_picklable() in task-sdk/src/airflow/sdk/api/client.py, used by both raise_on_4xx_5xx and raise_on_4xx_5xx_with_note: anything raise_for_status() raises outside the 400-599 range now gets wrapped in a ServerResponseError (picklable) before propagating. Errors inside 400-599 that from_response() couldn't extract a JSON detail
from are left exactly as before -- this only closes the gap for status codes get_json_error() never attempted to wrap in the first place.


Was generative AI tooling used to co-author this PR?
  • Yes -- Claude Code (Sonnet 5) for writing test

get_json_error() only wraps 400-599 responses in the picklable
ServerResponseError (it needs a custom __reduce__ because plain
httpx.HTTPStatusError requires keyword-only request/response arguments
pickle's default reconstruction can't supply -- see apache#47873, fixed for
that path by apache#48517). A 3xx response -- e.g. a corporate proxy in
front of the API server returning a redirect -- falls outside that
range, so httpx.Response.raise_for_status() raises the bare,
unpicklable httpx.HTTPStatusError instead.

That bare exception crashes the scheduler once it crosses a
multiprocessing boundary: LocalExecutor.result_queue is a
multiprocessing.Queue, and unpickling the exception on the scheduler
side fails with the exact "missing keyword-only arguments" TypeError
apache#47873 first reported, just triggered by a redirect instead of a
JSON error body.

_raise_for_status_picklable() now wraps anything raise_for_status()
raises outside the 400-599 range in a ServerResponseError too, while
leaving in-range errors that from_response() couldn't parse a JSON
detail from exactly as before.
@ColtenOuO
ColtenOuO force-pushed the fix-scheduler-crash-on-3xx-redirect branch from 27cf1f2 to 97f0e4b Compare August 22, 2026 02:58
@potiuk potiuk added the closed because of open PR limit Closed as a one-time step of introducing the open pull request limit label Sep 25, 2026
@potiuk

potiuk commented Sep 25, 2026

Copy link
Copy Markdown
Member

Hello @ColtenOuO - 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 19 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 gh pr reopen <PR_NUMBER> --repo apache/airflow. Reopen the ones you are ready to follow through - keep them rebased, respond to review comments and fix failing checks.

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

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

Labels

area:task-sdk closed because of open PR limit Closed as a one-time step of introducing the open pull request limit

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Scheduler crash when API server returns 301 or redirection through proxy

2 participants