We have a staging application on LiveKit Cloud Build that uses RoomService.CreateRoom and AgentDispatchService.CreateDispatch with a self-hosted agent worker. Our server releases its pre-created usage reservation when Cloud definitively rejects admission. We have already verified the real SDK-to-database path locally with a simulated HTTP 429, but our acceptance criterion asks for a genuine Cloud-side quota/limit refusal.
We do not want to exhaust shared Build allowances, burst Server API traffic, upgrade the plan, or disrupt other sessions just to force an error. Is there an officially supported low-impact or isolated way to trigger a real CreateRoom or CreateDispatch quota rejection for this test (for example, a temporary test cap)? If not, do you recommend retaining the local integration test and waiting for a naturally occurring Cloud refusal? Which status/error shape should the server expect for these APIs?
No project identifiers, credentials, or logs are included here. Thanks.
@LinSH, On Build there is no self-serve test cap: limit increases are a Scale-plan feature requested through project settings (quotas & limits), so Build has no dashboard knob to lower a quota on demand.
Forcing a real refusal on your project: the only self-serve limit that is isolated to your project is the Server API rate limit of 1,000 requests per minute (same page). Bursting it returns a real Cloud 429 through the normal SDK path and touches no shared allowance or other session, so the per-project scope removes the disruption concern, though it is a rate-limit refusal, not the concurrency/quota refusal your criterion likely means. For a genuine quota refusal without exhausting allowances, ask support to apply a temporary concurrency cap on the staging project, then restore it.
Keep the local test: yes. Your local 429 test already exercises the SDK-to-database reservation-release path, which is the actual logic under test. A real Cloud refusal only re-validates the error shape, not the release behavior, so pin the shape in a contract test and do not gate acceptance on a naturally occurring refusal.
Error shape: the server SDK calls both APIs over Twirp, so a rejection returns a structured Twirp error. The Python SDK raises ServerError with .code (string), .message, .status (HTTP status), and .metadata (twirp_client.py). The 1,000/min rate limit returns HTTP 429, matching your simulation; a concurrency/quota admission refusal is a separate case whose exact .code and .status are not pinned in the open-source SDK. Assert on .status plus .code, and confirm the concurrency-refusal values with support.