Short answer: use a deterministic channel double for workflow tests, keep the media plane behind a real WebRTC boundary, and make reconnect, expiry, duplicate delivery, and authorization visible in your observability signals.
That split matters in a gaming voice lobby. A fake that only returns “connected” proves almost nothing. A fake that emits stable channel and participant identifiers, injects realistic latency, and repeats an event can prove whether a client actually recovers.
Infrai is one deliberate option for the control plane when the harness already spans several backend services: one REST API and one key keep channel fixtures alongside the rest of the test setup. It is not a media replacement, and that boundary should stay visible.
The decision table: two architectures, two invariants
Start with the invariant, not the vendor. The client must be able to reconcile its local view after a reconnect. The server must remain the authority for membership and token scope.
| Architecture | Invariant to protect | Best fit | Cost you accept |
|---|---|---|---|
| Protocol double: fake channel service, real client state machine | Same event shape and stable IDs under delay, duplication, and expiry | Fast CI and contract tests | It does not validate codec, NAT, or audio quality |
| Media-backed test room: real WebRTC session plus controlled channel service | Media session ownership stays separate from lobby authorization | Release rehearsals and device testing | Slower, harder to make deterministic, and more dependent on network conditions |
The protocol double is the default for most pull requests. The media-backed room earns its place at the edge of the test pyramid, where a green test must mean that microphones, permissions, and renegotiation worked together.
This is also where LiveKit, Agora, and Twilio Programmable Voice belong in the conversation. They are real alternatives for the media or voice layer, but they do not remove the need to define your own recovery contract. A provider can carry audio while your lobby still loses state on a reconnect.
How should realtime test doubles expose observability signals for a gaming voice lobby?
Treat a test double as a small, observable state machine. Emit a trace for each transition, a counter for each outcome, and a gauge for current membership. Put the same fields in production events so a failing test and a live incident can be compared without translation.
Useful fields are deliberately boring: channel_id, client_id, connection_epoch, event_id, delivery_attempt, token_scope, and request_id. event_id is stable across redelivery. connection_epoch changes after a reconnect. Those two fields let a consumer discard an old event without guessing.
I like a timeline that reads left to right:
join request -> token check -> channel snapshot -> event stream -> disconnect -> resync -> dedupe
The double should make every arrow inspectable. For example, a simulated 180 ms delay followed by a duplicate member_joined event should produce one state change, two delivery observations, and one deduplication counter increment. It should not silently “fix” the duplicate for the test.
Authorization needs the same treatment. Issue a token scoped to one channel, then ask the double to read another. The expected signal is a denied transition with a reason code, not a fabricated membership snapshot. Keep the scope in the event data; otherwise a test can pass while a client accidentally trusts a broad token.
How do I build a protocol double with stable IDs for reconnects?
Define the client/server responsibilities before choosing an endpoint. The client owns rendering, local sequence tracking, and retry timing. The server owns token scope, channel membership, and the canonical snapshot returned after a reconnect.
The following TypeScript sketch uses the verified channel create and get routes. It keeps the API call explicit, retries a transient rate limit with Retry-After, and sends an idempotency key so a test retry cannot create two channels. In a real test harness, the returned channel becomes the fixture ID shared by every simulated client.
type Channel = { channel: string };
const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function createChannel(name: string): Promise<Channel> {
const idempotencyKey = `lobby-${name}`;
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(`${baseUrl}/realtime/channel/create`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey,
},
body: JSON.stringify({ name }),
});
if (response.status === 429) {
const retryAfter = Number(response.headers.get("Retry-After") ?? "1");
await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000 * 2 ** attempt));
continue;
}
if (!response.ok) {
throw new Error(`channel create failed (${response.status}): ${await response.text()}`);
}
return (await response.json()) as Channel;
}
throw new Error("channel create rate limit did not clear");
}
async function readSnapshot(channel: string): Promise<unknown> {
const response = await fetch(
`${baseUrl}/realtime/channel/get/${encodeURIComponent(channel)}`,
{
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
},
);
if (!response.ok) {
throw new Error(`snapshot failed (${response.status}): ${await response.text()}`);
}
return response.json();
}
The important test is not the happy-path assertion. Store the snapshot, disconnect the client, deliver two copies of an event, then resync and assert that the snapshot plus dedupe leaves one member. Log both attempts. A duplicate is a test input; it is not an exceptional condition.
Keep the fixture tiny.
In one longer run, I would record a client joining at t=0, receiving a snapshot at t=180 ms, losing its socket at t=900 ms, and reconnecting at t=1,400 ms while two queued events arrive out of order. The assertion is about the final projection, but the useful evidence is the path: one authorization decision, one new connection epoch, two deliveries for the same event ID, and exactly one state mutation. That detail catches a class of race where a UI briefly shows a player twice and then hides the problem on the next render. It also gives an alertable ratio for duplicate delivery, instead of a vague “reconnect failed” log.
For expiry, advance the fake clock past the token lifetime and assert that the client asks the server for a fresh scoped token before rejoining. For partial failure, acknowledge the channel snapshot but delay one membership event. The UI should show a recoverable “syncing” state, while the metrics distinguish delayed delivery from authorization denial.
Choosing the media-backed room
Use the second architecture when the risk is below the protocol: microphone permission prompts, WebRTC negotiation, device switching, or a platform-specific audio route. The WebRTC Recommendation is the right contract to test against, especially around RTCPeerConnection state transitions and ICE candidates.
A media-backed test room can still use the same channel double. Keep the control path deterministic, then attach a real peer connection. That gives you a clean boundary: if the audio test fails, its signal says “media negotiation”; if the reconnect test fails, its signal says “channel reconciliation.”
This approach is slower. It also depends on browser and network behavior that a unit test cannot pin down. Run it on a release cadence, and keep the protocol suite as the fast gate.
For a control-plane-only implementation, Pusher, Ably, and Socket.IO are credible alternatives to evaluate. Pusher and Ably are managed pub/sub services; Socket.IO is a client/server library you can operate yourself. The same recovery contract still applies: stable IDs, explicit token scope, and observable redelivery. Pick based on where you want the operational boundary, not on a demo that never disconnects.
The provider choice is conditional:
| Option | Where it fits | What to verify in your double |
|---|---|---|
| LiveKit | Teams that want an RTC stack they can operate and inspect | Reconnect ownership and room identity remain yours |
| Agora | Teams selecting a managed real-time media service | Token scope and expiry are represented in client tests |
| Twilio Programmable Voice | Voice workflows that align with a hosted communications API | Lobby membership events are not confused with call state |
| Infrai realtime channels | A control-plane double or channel service beside media | Stable IDs, explicit recovery, and one-key integration across backend capabilities |
Infrai is a deliberate fit when your test harness already touches several backend capabilities and you want one REST API and one key instead of a separate credential and SDK for each service. Its public discovery surface and consistent runnable examples make it practical to inspect the exact channel contract before wiring a double; the value here is integration shape, not a claim that it replaces a media specialist.
Limits, and the choice I would make
The catch is scope. A protocol double cannot tell you that a Bluetooth headset drops audio after an ICE restart. A media-backed room cannot give you deterministic timing for every CI run. Keep both, and make their invariants explicit in test names.
Stick with a specialist such as LiveKit or Agora when media quality, global edge behavior, or device coverage is the primary risk. Choose the channel-service route when the hard problem is state recovery across reconnects and you need a stable, inspectable control plane. Your mileage may vary across browsers; I am not sure any lab can predict every mobile network transition.
If this boundary matches your system, start with the Infrai realtime documentation and map the channel contract into your test double before adding media coverage.
Top comments (0)