[Python 3.14 proxy worker] Missing sys.modules["__main__"] breaks multiprocessing spawn
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
Research direction
Start by locating the Python 3.14 proxy_worker dependency-cleanup path described in the investigation and reproduce the failure with the minimal multiprocessing spawn example. Trace why main is removed, then verify that the reproduction can start and join the child process successfully without breaking the worker cleanup behavior.
Written by the indexing model from the issue text.
Description
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-functionsapplication 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.
- Dominant language
- Python
- Stars
- 357
- Forks
- 117
- Avg merge
- 13d 12h
- Merged PRs (30d)
- 2
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/azure-functions-python-worker
-
[Bug] ASGI cookie conversion serializes an absent Domain attribute and breaks __Host- cookiesPossibly taken @tharun06 claimed this 14 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 5/5 Over a week Newbie friendliness 28/100
Azure/azure-functions-python-worker#1908 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Azure/azure-functions-python-worker#1906 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
bug python
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Azure/azure-functions-python-worker#1887 · 1 reaction ·
All issues in Azure/azure-functions-python-worker
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
data-umbrella/du-event-board#225 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100