Python Workers: NoGilError race condition during concurrent request initialization (preparePython)

[cooperjbrandon]

Bug Description

Python Workers using FastAPI throw NoGilError: Attempted to use PyProxy when Python GIL not held when multiple concurrent HTTP requests hit the same isolate. The error occurs in the runtime's preparePython/initPyInstance code path — not in application code.

Stack Trace

NoGilError: Attempted to use PyProxy when Python GIL not held
    at throw_no_gil (pyodide-internal:generated/emscriptenSetup:20688:13)
    at wasm://wasm/020fb45e:wasm-function[432]:0x117f9b
    at python_getattr (pyodide-internal:generated/emscriptenSetup:23035:13)
    at Object.get (pyodide-internal:generated/emscriptenSetup:23106:119)
    at async preparePython (pyodide:python-entrypoint-helper:202:28)
    at async initPyInstance (pyodide:python-entrypoint-helper:258:24)
    at async Proxy.<anonymous> (pyodide:python-entrypoint-helper:300:36)

Reproduction

1. Deploy a Python Worker with FastAPI that makes async HTTP calls
2. Send 3-5 concurrent requests to different endpoints on the same worker
3. Observe NoGilError on some requests, with outcome exception

The error is more likely when:

• Requests involve CPU-bound work
• Multiple requests arrive within the same ~100ms window
• The isolate is handling concurrent requests in stateless execution mode

Environment

• compatibility_date: 2025-12-01 NOTE I just bumped my compat date to 2026-04-01, so perhaps that will help too.
• compatibility_flags: ["python_workers"]
• Execution model: stateless
• Observed in deployed staging environment (not local dev)

Analysis

The race condition appears to be in the isolate re-use logic. When a second request arrives while the first is awaiting I/O (GIL released), preparePython for the second request tries to access a Python proxy object, but the GIL acquisition fails — likely because the first request's coroutine is resuming or the V8 snapshot restoration leaves the GIL in an inconsistent state.

All application code uses async/await correctly (no threading, no blocking I/O). The error is entirely within pyodide-internal and python-entrypoint-helper.

[cooperjbrandon]

Update: Also affects scheduled() cron triggers with zero concurrency

We're seeing the same NoGilError crash on cron invocations (*/5 * * * *) — single scheduled() call, no concurrent requests.

Error chain:

There is no 'Default' class defined in the Python Worker's main module
NoGilError: Attempted to use PyProxy when Python GIL not held
Recursive call to fatal_error

This points to a cold-start initialization race in Pyodide itself, not request concurrency. ~30-40% of cron runs fail intermittently. Still reproducing on compatibility_date: 2026-04-01.

[hoodmane]

@cooperjbrandon so far we haven't been able to reproduce this. Would you be willing to share an example repository with a reproducer?

[cooperjbrandon]

Thanks @hoodmane .

It's definitely happening at platform level, but I also see logs on my end that it periodically happens on application level (something inefficient with my code essentially). Ie I have a cron that runs every 5 minutes. The platform error and the application errors don't overlap though, they take turns in blocks:

• NoGilError: 2:15pm-2:50pm, then 11:20pm-5:00am (overnight)
• Application code error: 11:35am-2:15pm, then 5:05am-present (daytime)

It could be that Cloudflare is recycling the Pyodide isolate periodically. When a fresh cold-start happens, it hits NoGilError (GIL initialization race). When it gets a warm reused instance, it hits my application code (stale event loop state from previous runs).

Essentially, i'll fix my application code, and see if the platform error goes away. If not, I'll throw up a quick example repo to reproduce this. Stay tuned!

[hoodmane]

I pulled down what you have in production (got the info from the cust-esc) and stripped the sensitive-looking stuff out and am trying to see if I can reproduce the error. So far I keep hitting other problems so I haven't reproduced it successfully.

The error is definitely interesting so whether or not you find a workaround that is good enough for your use case, it would be great if we could understand what is happening here and make it not happen.

[cooperjbrandon]

odd.....

But cool, appreciate that. Will do. I'll keep you posted.

[hoodmane]

What are your dependencies in pyproject.toml?

[cooperjbrandon]

[project]
name = "***"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
    "fastapi",
    "pydantic",
    "httpx",
]

compatibility_date = "2026-03-17"
compatibility_flags = ["python_workers"]

[cooperjbrandon]

Update: fixing the application code resolved both errors — the application-level RuntimeError AND the NoGilError. Zero errors for the past 9 hours since deploying the fix.

What was happening:

Our scheduled() handler was using asyncio.gather() with 3 concurrent httpx HTTP calls, looped sequentially ~50 times within a single cron invocation. This same asyncio.gather() pattern works fine in fetch() handlers — it only failed in scheduled().

The application-level error was: RuntimeError: Cannot enter into task <PyodideTask> while another task is being executed — a Pyodide event loop contention issue from the concurrent tasks.

What fixed it:

Moved the asyncio.gather() / httpx calls out of the scheduled() handler entirely. The cron now only does simple KV reads/writes — no concurrent async HTTP calls.

Theories on why scheduled() behaves differently than fetch():

1. Cumulative event loop corruption — a fetch() request does one asyncio.gather() and exits. The cron did it ~50 times in a loop within a single invocation, possibly accumulating stale task state in the Pyodide event loop.
2. Different runtime initialization — fetch() goes through the ASGI bridge which may set up the Python/GIL context differently than scheduled() calling Python directly from the WorkerEntrypoint class.
3. Cascade effect — the application-level error may have corrupted the warm isolate's state, causing subsequent cron invocations to hit NoGilError on re-initialization. This would explain why the two errors alternated in blocks rather than co-occurring.

The underlying issue — asyncio.gather() with concurrent httpx calls failing in scheduled() but not fetch() — still seems like a real bug. I'll try to create a minimal example repo to reproduce this.