Repository navigation
Conversation
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.
27cf1f2 to
97f0e4b
Compare
|
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 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 |
closes: #49099
Summary
get_json_error()only wraps 400-599 responses in the picklableServerResponseError-- it needs a custom__reduce__because a plainhttpx.HTTPStatusErrorrequires keyword-onlyrequest/responsearguments 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, unpicklablehttpx.HTTPStatusErrorinstead. That crashes the scheduler once the exception crosses a multiprocessing boundary:LocalExecutor.result_queueis amultiprocessing.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()intask-sdk/src/airflow/sdk/api/client.py, used by bothraise_on_4xx_5xxandraise_on_4xx_5xx_with_note: anythingraise_for_status()raises outside the 400-599 range now gets wrapped in aServerResponseError(picklable) before propagating. Errors inside 400-599 thatfrom_response()couldn't extract a JSON detailfrom 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?