[Bug]: Prisma query engine crashes immediately on first query on Windows (pip install) - LiteLLM 1.82.x / 1.83.0

[gfish213-tech]

Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

Environment

OS: Windows 10/11 x64
Python: 3.12.x (pythoncore-3.12-64)
LiteLLM versions affected: 1.82.0, 1.82.3, 1.83.0
LiteLLM last working version: 1.81.16
Installation method: pip (not Docker)
prisma-client-py: 0.15.0
Prisma CLI: 5.17.0
Node.js: v20.19.1 (also reproduced with v24.14.1)
PostgreSQL: 15.x at 127.0.0.1:5432
Virtual environment: Python venv at C:\LiteLLM\venv

What happened?
After upgrading from LiteLLM 1.81.x to any 1.82.x or 1.83.0 release via pip on Windows, the Prisma query engine crashes immediately on the first database query after startup. LiteLLM becomes completely unable to read from or write to the PostgreSQL database.
The Prisma migrations run successfully. The query engine binary is found and its PID is logged. However the very first query LiteLLM makes after startup returns httpcore.ReadError, indicating the engine process crashes mid-response. All subsequent queries fail with httpcore.ConnectError: All connection attempts failed because the engine process is dead.
Critically: The Prisma engine works perfectly fine in isolation. A standalone Python test script connecting to the same database with the same DATABASE_URL succeeds without any issues:
pythonimport asyncio
from prisma import Prisma

async def test():
db = Prisma()
await db.connect()
print('SUCCESS - connected!')
await db.disconnect()

asyncio.run(test())

Output: query-engine 393aa359c9ad4a4bb28630fb5613f9c281cde053

SUCCESS - connected!

This confirms the issue is in how LiteLLM 1.82.x/1.83.0 initializes or interacts with the Prisma client internally — not in Prisma, the binary, the database, or the network.

Relevant log output (with --debug)
query-engine 393aa359c9ad4a4bb28630fb5613f9c281cde053
LiteLLM Proxy:INFO: utils.py - Started Prisma DB health watchdog
LiteLLM Proxy:INFO: utils.py - Found prisma-query-engine at PID 29404.
LiteLLM Proxy:INFO: utils.py - Watching engine PID 29404 via os.kill polling.

LiteLLM Proxy:ERROR: proxy_server.py - litellm.proxy_server.py::add_deployment() - Error getting new models from DB -
File "prisma/engine/_http.py", line 217, in request
httpcore.ReadError <-- engine crashes on FIRST query

LiteLLM Proxy:ERROR: utils.py - LiteLLM Prisma Client Exception get_generic_data: All connection attempts failed
LiteLLM Proxy:ERROR: utils.py - LiteLLM Prisma Client Exception get_generic_data: All connection attempts failed
LiteLLM Proxy:ERROR: proxy_server.py - ProxyConfig:add_deployment - All connection attempts failed
File "prisma/engine/_http.py", line 217, in request
httpcore.ConnectError: All connection attempts failed <-- engine is dead, all subsequent queries fail

What I expected
LiteLLM should connect to PostgreSQL via Prisma and start successfully, as it did in 1.81.16.

What actually happened
The Prisma query engine process starts (PID is found and logged), but crashes on the very first query LiteLLM makes after startup (ReadError). All subsequent queries fail with ConnectError because the engine process is no longer running.

Steps to reproduce

Windows 10/11 x64, Python 3.12, pip install (not Docker)
Create a fresh venv: python -m venv venv
Install: pip install "litellm[proxy]==1.83.0"
Install prisma separately (not pulled in automatically): pip install prisma
Fetch binaries: cd venv/Lib/site-packages/litellm/proxy && prisma py fetch --force
Generate client: prisma generate --schema schema.prisma
Set DATABASE_URL environment variable to a valid PostgreSQL URL
Run: litellm --config config.yaml --debug
Observe ReadError on first query, then ConnectError on all subsequent queries

Additional investigation done
The following were ruled out as causes:

✅ PostgreSQL is running and accessible — standalone Prisma test script connects successfully
✅ DATABASE_URL is correctly set — confirmed via python -c "import os; print(os.environ.get('DATABASE_URL'))"
✅ Prisma binary is downloaded — prisma version shows correct binary at cache path
✅ Node.js version — reproduced with both v20.19.1 (LTS) and v24.14.1
✅ HTTP/HTTPS proxy vars — cleared $env:HTTP_PROXY, $env:HTTPS_PROXY, set $env:NO_PROXY=localhost,127.0.0.1 — no change
✅ Windows Defender — not blocking the binary (binary runs standalone)
✅ Fresh venv — reproduced on completely fresh virtual environment
✅ prisma py fetch --force — binaries downloaded successfully
✅ prisma generate --schema schema.prisma — client generated successfully
✅ Downgrading to litellm==1.81.16 — fixes the issue completely

Steps to Reproduce

Relevant log output

What part of LiteLLM is this about?

No response

What LiteLLM version are you on ?

v1.53.0

Twitter / LinkedIn details

No response

[kuun993]

+1

[LoadingZhang]

+1, linux too

[552176426]

+1，windows，1.83.11 version

[552176426]

help...

[webber84]

same problem with 1.83.14.

Gemini provided following solution, which worked perfectly for me:

🐛 The Root Cause
The issue stems from the Prisma DB health watchdog inside LiteLLM. It attempts to check if the underlying Prisma query-engine process is alive by polling it with os.kill(engine_pid, 0).

However, calling os.kill(pid, 0) on Windows can unexpectedly throw an OSError (such as permission denied or invalid parameter). This unhandled exception inside the async watchdog task cascades into a CancelledError, which forcefully shuts down the entire main event loop (Uvicorn).

🛠️ The Workaround
To fix this temporarily, you can disable the os.kill polling mechanism in the LiteLLM source code.

Open your Python site-packages directory and find this file:
...\site-packages\litellm\proxy\utils.py

Search for the log string: "via os.kill polling" (around line 4076).

Right below that log, comment out the os.kill execution and replace it with pass.

The line I commented out is 3998 as below:

async def _poll_engine_proc(self) -> None:
"""poll via os.kill(pid, 0) every 1s.
Only used when BOTH waitpid thread and pidfd are unavailable
(e.g., PID is not our child process and pidfd_open fails)
"""
while self._watching_engine and self._engine_pid > 0:
try:
#os.kill(self._engine_pid, 0)
except ProcessLookupError:

[gfish213-tech]

wow, the tip given really work, i tried again with 1.85.1.

def _is_engine_alive(self) -> bool:
    if self._engine_pid <= 0:
        return True
    try:
        # os.kill(self._engine_pid, 0)   <---------- remark this
        return True
    except ProcessLookupError:
        return False
    except (PermissionError, OSError):
        return True

---

async def _poll_engine_proc(self) -> None:
    """poll via os.kill(pid, 0) every 1s.
    Only used when BOTH waitpid thread and pidfd are unavailable
    (e.g., PID is not our child process and pidfd_open fails)
    """
    while self._watching_engine and self._engine_pid > 0:
        try:
            # os.kill(self._engine_pid, 0) <---------- remark this
            pass <---------------------------------- add this
        except ProcessLookupError:
            verbose_proxy_logger.error(
                "prisma-query-engine PID %s gone; triggering reconnect.",
                self._engine_pid,
            )
            self._engine_confirmed_dead = True
            self._reap_all_zombies()
            self._cleanup_engine_watcher()
            await self.attempt_db_reconnect(
                reason="engine_process_death",
                force=True,
            )
            return
        except (PermissionError, OSError):
            verbose_proxy_logger.debug(
                "Cannot signal PID %s; stopping engine poll.",
                self._engine_pid,
            )
            self._cleanup_engine_watcher()
            return
        await asyncio.sleep(1)

[kantawitarm]

A fix for this is ready for review in PR #30831. It replaces os.kill(pid, 0) with Popen.poll() is None on Windows inside _is_engine_alive_windows(), which checks process liveness without routing through TerminateProcess.