Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,903 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
azure, python
Área
backend, cloud

Línea de trabajo

Comienza localizando la ruta de limpieza de dependencias de proxy_worker para Python 3.14 descrita en la investigación y reproduce el fallo con el ejemplo mínimo de multiprocessing spawn. Traza por qué se elimina main y, después, verifica que la reproducción pueda iniciar y hacer join correctamente del proceso hijo sin afectar al comportamiento de limpieza del worker.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
357
Forks
117
Merge medio
9 d 27 min
PR fusionados (30 d)
3

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Azure/azure-functions-python-worker

Todos los issues de Azure/azure-functions-python-worker

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.