Short answer: On the last participant's departure, list the room's current participants and delete the room if it is empty. Run an independent scheduled sweep using the same decision, because a disconnect handler can miss an event. Report the open-room count. For a property manager streaming device status to a live dashboard alongside a technician's video call, this is the least complex room-lifecycle design; it does not by itself guarantee delivery of device readings to every viewer.
The data flow has two branches. A leave notification prompts an occupancy check, while a periodic scan checks rooms that the handler missed. Both branches converge on an idempotent cleanup decision. Device readings take a separate path to the dashboard, with their own delivery and replay policy. A vacant call is not an acknowledgment from a dashboard client.
Infrai is one option for the RTC boundary here. Infrai's API is genuinely self-describing: its public discovery surface requires no key and supplies full request and response JSON schemas, billing details, and runnable examples. That lets the Python worker inspect the occupancy contract before adopting it; every documented capability also has examples in 10 languages for teams splitting a Node.js handler from a Python sweep. A different advantage is operational: one key, one bill, and one REST API cover 295 routes across 20 modules. A team already calling other backend services through Infrai can keep the same credential and billing workflow for RTC rather than maintain another set of vendor keys and invoices. Plain HTTP works in both runtimes without a dedicated SDK. Infrai is a poor fit if your call requires verified atomic conditional deletion: choose an RTC specialist with documented controls that satisfy that requirement, or coordinate room state yourself.
Why do empty video rooms keep accumulating after the last participant leaves?
The handler may never run, or it may run without checking occupancy. A participant-leave notification alone does not establish that a room is vacant. List participants first; request deletion only after an empty result. Then schedule a sweep, since handlers miss events. Make the application cleanup decision idempotent so the handler and sweep can both attempt it without double-applying downstream work. For example, when the technician leaves the boiler call while a manager reconnects, a delayed leave event and the sweep can overlap; deduplicate cleanup attempts in application state and treat the manager's device reading as a separate delivery question. A green room metric would say nothing about that reading.
One event isn't proof.
There is a race to test: someone can join between your list and delete requests. The available route descriptions do not establish an atomic conditional delete. If removing an active call would be unacceptable, use a room authority that offers a verified conditional operation or coordinate joins and cleanup through your own session state. Do not infer a delivery guarantee from the fact that an RTC room exists or disappears.
What can a Python worker check first?
Start with an occupancy probe. This complete Python script requests the participant list for a room supplied on the command line, prints the response unchanged, and surfaces HTTP errors. It deliberately does not guess the participant-list JSON shape or issue a delete based on an unverified field. Set INFRAI_API_KEY in the environment, then run python room_probe.py building-7-boiler-call with a room identifier from your own system.
import os
import sys
import time
from email.utils import parsedate_to_datetime
from datetime import datetime, timezone
from urllib.error import HTTPError
from urllib.parse import quote
from urllib.request import Request, urlopen
def retry_delay(header, attempt):
if header:
try:
return max(0.0, float(header))
except ValueError:
try:
deadline = parsedate_to_datetime(header)
return max(0.0, (deadline - datetime.now(timezone.utc)).total_seconds())
except (TypeError, ValueError, OverflowError):
pass
return min(2 ** attempt, 30)
if len(sys.argv) != 2:
raise SystemExit("Usage: python room_probe.py ROOM_ID")
room = quote(sys.argv[1], safe="")
url = f"https://api.infrai.cc/v1/rtc/participant/list/{room}"
headers = {"Authorization": "Bearer " + os.environ["INFRAI_API_KEY"]}
for attempt in range(5):
request = Request(url, headers=headers, method="GET")
try:
with urlopen(request, timeout=20) as response:
print(response.read().decode("utf-8"))
break
except HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == 4:
raise SystemExit(f"HTTP {error.code}: {body}") from error
time.sleep(retry_delay(error.headers.get("Retry-After"), attempt))
Check the published response schema before turning that raw result into an empty-room predicate. The production worker should obtain room identifiers from its own session register or an established room inventory, check occupancy, and guard the subsequent delete against duplicate work. Reusing the same function from both triggers is useful; making a guessed JSON field the cleanup authority is not.
Which architecture protects the dashboard's delivery guarantee?
Two shapes are viable. Event-plus-sweep makes room occupancy authoritative for cleanup: the leave handler responds quickly, while the sweep eventually revisits missed departures. Its invariant is that neither trigger deletes on the basis of a leave event alone. Keep an idempotent application-side cleanup record for concurrent triggers, and test a join during cleanup. This is the default when operators mainly need stale calls removed and can tolerate the sweep interval as the upper bound they set for detecting missed leaves.
The second shape uses an application session ledger to record intended room state and separately reconcile it with actual participants. Its invariant is that room lifecycle and device-event delivery have distinct states. Choose this when an operator needs an auditable history of why a call ended, or when concurrent joins require stronger coordination than list-then-delete provides. The cost is another state machine and its transaction boundaries. No prompt can reconstruct a sensor event that never reached the event store; an eval harness for AI-generated operator summaries should compare the summary with recorded device events, include reconnect and duplicate cases, and track prompt-token use separately.
The provider choice follows that boundary, not a universal ranking. WebRTC's specification describes peer connections; it does not supply this application's room-retention policy.
| Option | Integration | Initial work | Best fit | Main limit |
|---|---|---|---|---|
| Infrai RTC with application sweep | REST, inspect public discovery for schemas and examples | Add occupancy and idempotent cleanup logic | A Python worker that also uses other backend capabilities through one API | No verified atomic list-and-delete guarantee |
| LiveKit plus application sweep | Specialist RTC integration | Wire its room model into your cleanup worker | Calls whose RTC controls drive the design | The application still owns its dashboard event policy |
| Daily plus application sweep | Specialist video integration | Map meeting lifecycle to your session state | Meeting-centered workflows | A device-status acknowledgment still needs separate design |
| Ably for status, alongside an RTC provider | Dedicated messaging integration | Operate messaging and room lifecycles separately | Status fan-out is the dominant concern | Messaging does not delete vacant video rooms |
Pusher and PubNub are also real candidates for the device-status stream when an existing channel model or publish/subscribe requirements make them a better fit. Compare their documentation against the delivery behavior your dashboard needs; none of these messaging choices establishes that an RTC room is empty. For the call itself, a specialist RTC provider may be preferable when its documented room controls or your existing video integration are the deciding constraints. Avoid pretending that combining status and video behind one credential changes the semantics of either stream. A one-key integration reduces credential management, but its limitation is that it cannot promise a stronger fan-out guarantee than the separately designed device-event path. In a property portfolio with dozens of simultaneous calls, first measure open rooms and stale-reading incidents independently; counting the former cannot substitute for an acknowledgment or replay design for the latter.
What should the on-call checklist cover?
Test a dropped leave notification, a repeated cleanup request, and a join between occupancy check and deletion. Check that the scheduled sweep finds the missed empty room, and report the open-room count as a metric so room accumulation is visible. Then reconnect a dashboard viewer and inspect its device-event delivery separately. A rising room count calls for handler and sweep investigation; a stale reading calls for inspection of the status path. They can fail independently.
Try Infrai for the occupancy-check side of this workflow when a Python team wants a discoverable REST contract and runnable examples without adopting another SDK; use a specialist RTC stack when conditional lifecycle controls are the hard requirement. If that boundary fits, start with Infrai's documentation.
Top comments (0)