Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Python 3.14 proxy worker] Missing sys.modules["__main__"] breaks multiprocessing spawn

Đang mở
  • Có gì không ổn?
#1,903 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
azure, python
Lĩnh vực
backend, cloud

Hướng nghiên cứu

Bắt đầu bằng cách xác định đường dẫn dọn dẹp dependency của proxy_worker trong Python 3.14 được mô tả trong phần điều tra, rồi tái hiện lỗi bằng ví dụ multiprocessing spawn tối giản. Truy tìm lý do main bị loại bỏ, sau đó xác minh rằng bản tái hiện có thể khởi động và join tiến trình con thành công mà không làm hỏng hành vi dọn dẹp của worker.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Description

The Azure Functions Python 3.14 proxy worker removes __main__ from
sys.modules before invoking application code.

As a result, Python's standard multiprocessing spawn context fails during
Process.start(), before the child process or its target function begins
executing.

This is not specific to any third-party package. The minimal reproduction uses
only azure-functions and the Python standard library.

Environment
  • Azure Functions Python runtime: 3.14
  • Python: 3.14.6
  • Azure Functions Core Tools: 4.12.0
  • Functions runtime: 4.1048.200.26180
  • Programming model: Python v2
  • azure-functions application package: 2.2.0
  • Reproduced locally inside the Functions worker
  • The same failure was observed after deploying the application to Azure Functions on Python 3.14

The same application code worked on the Python 3.12 Functions runtime.

Minimal reproduction
import multiprocessing
import sys

import azure.functions as func

app = func.FunctionApp()


def child_process() -> None:
    return None


@app.route(route="multiprocessing-repro")
def multiprocessing_repro(req: func.HttpRequest) -> func.HttpResponse:
    main_present = "__main__" in sys.modules

    context = multiprocessing.get_context("spawn")
    process = context.Process(target=child_process)
    process.start()
    process.join()

    return func.HttpResponse(
        f"__main__ present: {main_present}; exit code: {process.exitcode}"
    )

Start the application using Core Tools with Python 3.14 and invoke
/api/multiprocessing-repro.

Actual behavior

"__main__" in sys.modules is false during the function invocation, and
Process.start() raises:

Traceback (most recent call last):
  File ".../multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File ".../multiprocessing/context.py", line 289, in _Popen
    return Popen(process_obj)
  File ".../multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File ".../multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File ".../multiprocessing/popen_spawn_posix.py", line 42, in _launch
    prep_data = spawn.get_preparation_data(process_obj._name)
  File ".../multiprocessing/spawn.py", line 164, in get_preparation_data
    main_module = sys.modules["__main__"]
KeyError: "__main__"

The failure occurs before the child process starts.

Expected behavior

The Functions worker should retain a valid __main__ module, or otherwise
initialize the application environment so that standard-library
multiprocessing spawn works inside a function invocation.

Investigation

The Python 3.14 worker uses proxy_worker. Its dependency cleanup appears to
remove modules from sys.modules based on their file location. It excludes
modules whose names begin with proxy_worker, but does not appear to exclude
__main__.

That appears to leave the invocation environment without the module required
by multiprocessing.spawn.get_preparation_data().

Launching an explicit Python subprocess with an importable module works in the
same Functions-host process, confirming that the failure is specifically in
the multiprocessing spawn preparation path.

Impact

Any application or dependency that uses the standard-library spawn context can
fail under the Python 3.14 Functions worker. In our application this prevented
all isolated document conversions from starting, regardless of document type.

Related issue

Related historical issue: #1094 reported the same missing-__main__ worker
condition on Python 3.9 through a different caller.

This report concerns the Python 3.14 proxy worker and reproduces through:

multiprocessing.get_context("spawn").Process(...).start()

It is therefore related behavior, but not the same caller or worker
implementation.

Ngôn ngữ chính
Python
Star
357
Fork
117
Merge trung bình
9 ngày 27 phút
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Azure/azure-functions-python-worker

Tất cả issue của Azure/azure-functions-python-worker

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.