What

uvicorn defaults timeout_keep_alive to 5 seconds and app.py never set it. This sets it explicitly to 120 s, overridable via MEMMACHINE_KEEP_ALIVE_SECONDS.

Why

A server keep-alive shorter than its clients' idle timeouts is a known hazard. Every client that fronts this server pools idle connections for longer than 5 s — Go's transport for 90 s, httpx for 5 s. A client can reuse a connection the server has just closed, and because POST is not idempotent it will not retry: it waits out its own timeout instead.

Setting the value above the largest client idle timeout in play removes that hazard.

What this does NOT do

It does not fix the 30-second stalls seen on this deployment, and should not be merged as though it does. Raising the value removed them from one load arm and not from another on the same image:

The change was verified live inside the running container in both cases (KEEP_ALIVE_SECONDS = 120, timeout_keep_alive present in start_http), so this is not a deployment mistake.

The two arms differ in think-times as well as in this setting, so the arm that showed zero may simply never have left a connection idle long enough to trigger the fault. The cause is unknown and the stall is still present at 0.4% of requests.

An earlier version of this PR claimed the first result as a confirmed fix. That was drawn from a single arm and was wrong.

The stall itself, for whoever picks it up

Still unexplained, and worth more than its rate suggests — each stall occupies a client slot for the full 30 s, which consumed roughly 47% of capacity in the 128-user arm.

• Requests hang for exactly 30.00 s (spread under 35 ms across 71 samples), matching restyTimeout in MemMachine-Platform internal/memmachine/core/client.go
• They never reach the application — over the same period the core completed 80,051 requests, all 200, none slower than 12,098 ms, zero above 30 s
• Only POSTs are affected; /health GETs stay green at ~1 ms throughout
• Neither end raises an error, which is why it went unnoticed

Note that AccessLogMiddleware logs after call_next returns, so a missing log line alone does not prove a request never arrived — the duration histogram is what rules out an internal stall.

Not measured

Holding connections open 24× longer keeps more sockets and file descriptors alive per idle client. Immaterial at the concurrency tested here; unknown at larger client counts.

ruff check and ruff format clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Nr9kacmpFVTTfkZRw6esxP