Bug Description

OpenViking currently starts the HTTP server with a single uvicorn worker:

uvicorn.run(app, host=config.host, port=config.port, log_config=None)

With this setup, one blocking or slow request can stall the entire server process. In practice, this means unrelated endpoints, including lightweight health endpoints such as /health, can stop responding while another request is in progress.

This is a serious availability issue for production use. A single slow request should not be able to block all HTTP traffic for the service.

From investigation, this appears especially risky because some async request paths ultimately perform blocking I/O underneath. When that happens, the single worker/event loop becomes unavailable, and the whole server becomes temporarily unresponsive.

This is not just a probe configuration problem. The underlying issue is that the server process has no isolation from blocking work. Under concurrent traffic, the entire API can be stalled by one request.

Steps to Reproduce

Start OpenViking with the default server startup path.
Confirm it is running with a single uvicorn worker.
Send a request that performs slow or blocking work.
At the same time, send repeated requests to a lightweight endpoint such as /health.
Observe that /health may also stop responding or time out while the slow request is running.

Expected Behavior

Lightweight endpoints such as /health should remain responsive even when other requests are slow.
One blocking request should not stall the entire HTTP server.
The server should be safe under concurrent traffic in production environments.

Actual Behavior

OpenViking runs with a single uvicorn worker.
A blocking or slow request like commit can stall the entire server.
Unrelated endpoints, including /health, may time out during that period.
This can trigger false liveness/readiness failures and make dependent services appear unhealthy.

Minimal Reproducible Example

Error Logs

OpenViking Version

latest

Python Version

3.10

Operating System

Linux

Model Backend

None

Additional Context

OpenViking currently does not appear to support configuring multiple uvicorn workers through its normal startup path.

I checked the current server bootstrap and config code:

openviking/server/bootstrap.py only accepts --host, --port, and --config
openviking/server/config.py defines ServerConfig with only host, port, root_api_key, and cors_origins
the actual server startup is:
uvicorn.run(app, host=config.host, port=config.port, log_config=None)
There is no --workers CLI flag, no workers field in ServerConfig, and no workers=... passed into uvicorn.run(...).

So, as of the current code, openviking-server effectively runs as a single uvicorn worker with no built-in way to configure multiple workers via CLI, config, or Helm values.

This matters because a single blocking or slow request can stall the whole HTTP server, including lightweight endpoints like /health, which is a production availability risk.