Tell me the exceptions of the LiveKit Room Service API's DeleteRoom method.

Thanks for reaching out, kira. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Tell me the exceptions of the LiveKit Room Service API's DeleteRoom method.

Thanks — I’m responding to your request about the exceptions (error cases) the LiveKit Room Service API’s

DeleteRoom

method can return. I don’t have a source that lists exact exception types/messages for

DeleteRoom

. LiveKit’s server APIs use the Twirp RPC framework, which returns structured error responses (error codes and messages). Based on that and related LiveKit guidance, these are the practical error cases you should expect and how to handle them: • Room not found / non-existent room ◦ What happens: Request to delete a room that does not exist or already deleted. ◦ How it appears: An error response indicating the resource was not found (Twirp “not_found”-style error). ◦ Suggested handling: Treat as idempotent — consider the delete successful or surface a clear “room not found” message to callers. • Invalid request (bad parameters) ◦ What happens: Invalid or malformed room identifier or request payload. ◦ How it appears: A client/validation error (Twirp “invalid_argument” or similar). ◦ Suggested handling: Validate inputs before calling DeleteRoom and return a 4xx-like error to the caller. • Authentication / authorization failure ◦ What happens: The client lacks valid credentials or required permissions to delete the room. ◦ How it appears: An authentication/authorization error (Twirp “unauthenticated” or “permission_denied”). ◦ Suggested handling: Verify API keys/tokens and RBAC/ACLs; instruct callers to refresh credentials or request appropriate permissions. • Concurrent modification / race condition ◦ What happens: Another operation is creating/deleting the same room concurrently, causing an operation conflict. ◦ How it appears: A conflict or precondition error (could be surfaced as “failed_precondition” or similar). ◦ Suggested handling: Retry with backoff, or surface a clear conflict error so the client can re-check room state. • Server unavailable / network / connection errors ◦ What happens: LiveKit server is down, unreachable, or the Twirp stream is closed before a response. ◦ How it appears: Transport-level errors (timeouts, connection closed, network errors). Example seen in tooling: “unable to create agent: server closed the stream before a response was received.” ◦ Suggested handling: Implement retries with exponential backoff and alerting if persistent. • Internal server error ◦ What happens: Unexpected server-side failure while handling the delete. ◦ How it appears: Internal error (Twirp “internal” or HTTP 500-equivalent). ◦ Suggested handling: Log the failure, surface an internal error to callers, and retry only if safe. If you need exact error codes/messages returned by your LiveKit deployment (for example, exact Twirp error code strings or the JSON error body), I’ll need one of the following so I can give precise details: • Which LiveKit version and SDK/language you’re using, or • A sample error response you’ve received from DeleteRoom, or • Confirmation you want me to list expected Twirp error codes mapped to HTTP equivalents. I can then map each case to specific Twirp error codes and example responses you can program against. Which of those would you like to proceed with? Sources: server-sdk-go | livekit/livekit_composite | DeepWiki | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name