CelesteRaine1783

Posted on Oct 5

Orphaned Chat Channel Cleanup: Scheduled Sweeps With Explicit Ownership Checks

#realtime #chat #channels

The bill for abandoned chat channels is made of retained channel state, repeated list-and-check work, and operational attention when nobody can explain who owns an old channel. The dominant term is usually retention, not the sweep itself: every channel kept forever remains one more object to enumerate and reason about on every later pass.

TL;DR: list channels on a schedule, compare every channel identifier with the application database's room table, and delete only channels with no owning room. Run the first sweep in alert-only mode. Once its reports stay quiet and the ownership query has proved trustworthy, enable deletion. The trade is deliberate: stop keeping transport objects after their application owners disappear, while accepting that post-incident inspection of those deleted channel objects is no longer available.

This is primarily a trust-boundary decision. A browser token should authorize a narrow client action; it should never authorize inventory or deletion. Keep the sweep, its broad credential, and the room-table lookup on a backend worker.

What actually drives retention cost?

Suppose the application owns 12,000 live rooms, while the realtime service lists 15,400 channels. The useful first number is the 3,400-object gap, not a speculative per-request price. Those example counts describe the arithmetic, not a benchmark: orphan_count = listed_channels - channels_with_an_owning_room. Measure the three inputs in your system before deciding that cleanup is worthwhile.

Names are not ownership evidence. A prefix such as room- can survive a failed provisioning flow, a renamed tenant, a test fixture, or a migration. Parsing it and guessing is attractive because it avoids a database query; it is also how a cleanup job turns an ambiguous string into an irreversible decision. The authoritative join is between the channel identifier returned by the realtime inventory and the identifier stored on the room row.

That join changes the dominant term. Instead of retaining every transport object indefinitely, the system retains only objects backed by application state, plus a short review window for newly reported orphans. The scheduled listing still costs work, but it is bounded and observable. Do not optimize that request before establishing whether the ownership comparison is correct.

How should a scheduled job clean unused chat channels?

Because a client is not an authority on global ownership. A user may leave a room while other users remain, a tab may hold stale state, and a compromised token must not become a channel-deletion credential. Scope client tokens to the channel and actions that the current session needs; place list and delete permissions in a server-side job whose credential never reaches the browser.

This separation also makes retries intelligible. Inventory is read-only. Deletion follows a second ownership check, close to the destructive call, so a room recreated between listing and deletion is preserved. There is still a race unless the application can serialize room creation and cleanup around the same ownership record. Where that guarantee is unavailable, quarantine candidates for another sweep rather than deleting immediately.

Small race, large consequence.

Treat ambiguity as “keep.”

A cautious sweep in Python

The following program uses the two verified realtime routes and leaves scheduling to the surrounding job runner. It defaults to report-only behavior; --delete is an explicit operational switch. Adapt extract_channel_ids only after inspecting the live response, because no cleanup job should pretend that an unverified response shape is stable.

import argparse
import os
import sqlite3
import time
from typing import Any
from urllib import error, parse, request
import json


BASE_URL = "https://" + "api." + "infrai." + "cc/v1"


def api_call(method: str, path: str, api_key: str) -> Any:
    req = request.Request(
        f"{BASE_URL}{path}",
        method=method,
        headers={"Authorization": f"Bearer {api_key}"},
    )
    for attempt in range(5):
        try:
            with request.urlopen(req, timeout=30) as response:
                return json.loads(response.read().decode("utf-8"))
        except error.HTTPError as exc:
            body = exc.read().decode("utf-8", errors="replace")
            if exc.code != 429 or attempt == 4:
                raise RuntimeError(f"API returned {exc.code}: {body}") from exc
            retry_after = exc.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else 2**attempt)
    raise RuntimeError("retry limit reached")


def extract_channel_ids(payload: Any) -> list[str]:
    if isinstance(payload, list) and all(isinstance(item, str) for item in payload):
        return payload
    raise RuntimeError("inspect the list response and update extract_channel_ids")


def room_exists(db: sqlite3.Connection, channel_id: str) -> bool:
    row = db.execute(
        "SELECT 1 FROM rooms WHERE realtime_channel_id = ? LIMIT 1",
        (channel_id,),
    ).fetchone()
    return row is not None


def sweep(db: sqlite3.Connection, api_key: str, delete: bool) -> None:
    payload = api_call("GET", "/realtime/channel/list", api_key)
    for channel_id in extract_channel_ids(payload):
        if room_exists(db, channel_id):
            continue
        print(json.dumps({"orphan": channel_id, "action": "delete" if delete else "alert"}))
        if delete and not room_exists(db, channel_id):
            safe_id = parse.quote(channel_id, safe="")
            api_call("DELETE", f"/realtime/channel/delete/{safe_id}", api_key)


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("--database", required=True)
    parser.add_argument("--delete", action="store_true")
    args = parser.parse_args()
    api_key = os.environ["INFRAI_API_KEY"]
    with sqlite3.connect(args.database) as db:
        sweep(db, api_key, args.delete)


if __name__ == "__main__":
    main()

The sample is intentionally suspicious of its inputs. It parameterizes the database lookup, percent-encodes the path segment, checks HTTP status through HTTPError, honors Retry-After on 429, and retries with exponential delay otherwise. A delete targets a named channel, so a retry cannot create a duplicate object; the second database lookup is the more important guard.

Run this against a replica only if its replication lag is inside the deletion safety window. A stale replica can say “missing” while the primary already contains the room. For the first deployment, omit --delete, retain the candidate reports, and reconcile them with room creation and deletion events. Automation comes after the false-positive count reaches zero for a meaningful review period, not after one tidy test run.

Scheduling, queues, and the credential boundary

Infrai exposes realtime and cron capabilities behind the same plain REST API and a single key, so a backend can schedule this sweep without installing another vendor SDK or maintaining a client-library version. That same credential boundary covers both capabilities: there is no second secret to rotate, map into the worker, or correlate during an audit. Its public, keyless discovery surface reports 295 routes across 20 modules, supplies full request and response schemas, and includes runnable examples in 10 languages; inspect the cron-create schema there rather than copying an invented request body. This matters because a scheduler's timeout and delivery semantics belong in the design, not in a hopeful comment, and because a discoverable contract gives the worker a concrete interface to validate before it can touch retained state.

The broader notification path has a related handoff: persist work for an offline user before attempting socket delivery. With one API key and base URL, the scheduled/queued side can hold that durable notification and the realtime side can deliver it. The cleanup script above passes the realtime channel identifiers into the application's durable room lookup; for notification delivery, the corresponding handoff is a durable message identifier feeding the realtime publish step. Do not claim that a successful enqueue means the browser received anything. A consumer must be idempotent because standard queues are at-least-once, retention cannot exceed 30 days, and a delayed message cannot exceed 604,800 seconds.

A Pusher plus Amazon SQS design is also reasonable, but it requires two service signups, two credential sets, separate permission policies, and application glue that translates an SQS delivery into a Pusher publish while preserving idempotency and tracing. The consolidated surface removes that credential and integration split; it does not remove the need for an application-owned room table, a durable notification identifier, or narrow browser tokens.

Comparing the real alternatives

Option	Scheduling and retention boundary	Token and client-trust posture	Main limitation for this sweep
Infrai	Realtime and jobs/queues share one REST surface and one server credential	Keep the broad key in the worker; issue narrow client tokens separately	The application still owns the authoritative room join and deletion policy
Pusher Channels + Amazon SQS/EventBridge Scheduler	Realtime, durable work, and scheduling cross AWS and Pusher boundaries	Separate credentials make the trust split explicit but add policy and glue work	Two signups, two credential sets, and custom delivery integration
Ably + an external scheduler	Ably supplies realtime channels; the scheduler and room database remain separate	Token capabilities can constrain client access	Cleanup ownership still comes from application data, not channel names
PubNub + an external scheduler	PubNub supplies realtime messaging; orchestration remains an application concern	Access Manager provides scoped authorization controls	Another scheduler and its credentials must participate in the sweep
self-hosted Socket.IO + a queue/scheduler	You control retention, workers, and deployment	Trust rules are entirely yours to implement and audit	Operations, durable delivery, inventory, and cleanup semantics are all your responsibility

None of these products can infer application ownership safely. Pusher, Ably, and PubNub are mature realtime choices when their client ecosystems or messaging features already fit the system. Socket.IO is attractive when protocol control and self-hosting justify operating the surrounding state. Infrai fits when a team values a plain REST integration and wants realtime plus scheduled work under one backend credential; that convenience should be weighed against the architectural independence of separate services.

What do you give up by deleting?

You lose the channel object as evidence. If an incident review later asks whether an abandoned room still had transport state, deletion has removed that direct artifact. Preserve the decision record instead: channel ID, room lookup result, observation time, deletion time, and request ID where available. Do not preserve message content merely because cleanup needs an audit trail; identifiers and decisions are enough for this purpose.

Set a retention period for those records, too. Keeping cleanup logs forever recreates the same mistake in a different table.

Delete less than you can prove.

The practical decision rule is strict: alert on the first run, require repeated absence from the authoritative room table, recheck immediately before deletion, and keep the privileged sweep off the client. If ownership cannot be proven, retain the channel and investigate. Storage hygiene is useful only while it remains less dangerous than stale state.

DEV Community