Component
API Server / GraphQL
Describe the Feature Request
The API server needs a way to protect interactive (human/frontend) request
capacity from being exhausted by internal background traffic. The intended
direction is priority-aware admission with backoff: requests carry an
origin/priority signal, the API preferentially admits high-priority
(interactive) requests when under load, and signals low-priority (background)
callers to back off — a fast, honest 429 + Retry-After — so the SDK
retries with adaptive backoff instead of the server accepting work it can't
finish in time.
This issue tracks the need at a high level. The exact mechanism, parameters,
and how load is measured are left to implementation and discovery.
Describe the Use Case
When an instance is processing heavy background work (generators, artifact
rendering, diffs, repository syncs, computed attributes) and a human is
using the application at the same time, both compete for the same finite
Gunicorn/uvicorn worker pool and the same Neo4j connection pool. Background
tasks call back into the same API servers over HTTP via the Python SDK, and
today there is no prioritization and no origin awareness at the API layer
— frontend and background requests are indistinguishable and compete on equal
footing. Under heavy background load the API can no longer serve the frontend,
and the application appears unresponsive.
The frontend must stay responsive regardless of background volume — delivered
transparently (customers don't manage priorities) and without permanently
starving background work, since the backlog must still drain. The guarantee
should hold across deployment sizes without operator tuning.
Additional Information
Component
API Server / GraphQL
Describe the Feature Request
The API server needs a way to protect interactive (human/frontend) request
capacity from being exhausted by internal background traffic. The intended
direction is priority-aware admission with backoff: requests carry an
origin/priority signal, the API preferentially admits high-priority
(interactive) requests when under load, and signals low-priority (background)
callers to back off — a fast, honest
429+Retry-After— so the SDKretries with adaptive backoff instead of the server accepting work it can't
finish in time.
This issue tracks the need at a high level. The exact mechanism, parameters,
and how load is measured are left to implementation and discovery.
Describe the Use Case
When an instance is processing heavy background work (generators, artifact
rendering, diffs, repository syncs, computed attributes) and a human is
using the application at the same time, both compete for the same finite
Gunicorn/uvicorn worker pool and the same Neo4j connection pool. Background
tasks call back into the same API servers over HTTP via the Python SDK, and
today there is no prioritization and no origin awareness at the API layer
— frontend and background requests are indistinguishable and compete on equal
footing. Under heavy background load the API can no longer serve the frontend,
and the application appears unresponsive.
The frontend must stay responsive regardless of background volume — delivered
transparently (customers don't manage priorities) and without permanently
starving background work, since the backlog must still drain. The guarantee
should hold across deployment sizes without operator tuning.
Additional Information