Realtime Participant Moderation in Node.js: Testing Stock Watchlists Without Flaky Timing

Short answer: use the smallest realtime surface that can moderate a participant, then make reconnect, expiry, duplicate delivery, and authorization outcomes explicit in the test. For a property-management team sharing a stock-trading watchlist, that usually means treating the room as a state machine and reconciling by stable participant and event identifiers, rather than sleeping for an arbitrary number of milliseconds.

The workflow is easy to describe and surprisingly easy to test badly. A broker or property manager opens a watchlist room, several colleagues move collaborative cursors, and an operator may remove a participant whose session is no longer authorized. Authentication state, subscription state, and business events are separate observations. A green WebRTC connection does not prove that the user may edit the watchlist.

How should Node.js tests handle realtime participant moderation for a stock watchlist?

Start with an explicit state model. The client can be connecting, active, expired, reconnecting, or closed; moderation can be allowed, pending, kicked, or denied. Cursor updates are business events, not proof of authorization. That distinction gives a test something concrete to assert when packets arrive out of order.

I keep one stable room identifier and one stable participant identifier in every test fixture. On reconnect, the client asks for the current participant list and folds the result into local state by identifier. If an old cursor event arrives twice, the reducer ignores the duplicate. If a participant is kicked while offline, the next reconciliation wins over a stale local presence badge.

Here is the small harness I use to exercise the read-and-moderate boundary. The retry helper honors Retry-After, and the assertion fails on a successful HTTP response that does not contain the identifiers needed for reconciliation.

type Participant = { id: string; status?: string };

const baseUrl = process.env.INFRAI_BASE_URL;
const apiKey = process.env.INFRAI_API_KEY;
if (!baseUrl || !apiKey) throw new Error("INFRAI_BASE_URL and INFRAI_API_KEY are required");

async function request(url: string, init: RequestInit, attempt = 0): Promise<Response> {
  const response = await fetch(url, {
    ...init,
    headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json", ...(init.headers ?? {}) },
  });
  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("Retry-After") ?? "1");
    await new Promise((resolve) => setTimeout(resolve, Math.min(retryAfter * 1000, 8000)));
    return request(url, init, attempt + 1);
  }
  if (!response.ok) throw new Error(`HTTP ${response.status}: ${await response.text()}`);
  return response;
}

export async function listAndCheck(room: string, expectedId: string): Promise<Participant> {
  const response = await request(
    `${baseUrl}/rtc/participant/list/${encodeURIComponent(room)}`,
    { method: "GET" },
  );
  const payload = (await response.json()) as { participants?: Participant[] };
  const participant = payload.participants?.find((item) => item.id === expectedId);
  if (!participant) throw new Error(`participant ${expectedId} is not present after reconciliation`);
  return participant;
}

export async function moderate(room: string, participantId: string): Promise<void> {
  const response = await request(
    `${baseUrl}/rtc/participant/kick/${encodeURIComponent(room)}`,
    { method: "POST", body: JSON.stringify({ participant_id: participantId }) },
  );
  if (response.status !== 200 && response.status !== 202) {
    throw new Error(`moderation was not accepted for ${participantId}`);
  }
}

The example deliberately does not infer a successful kick from a local button click. A production test would call moderate, then reconnect the affected client and assert a terminal kicked state. It would also run the same scenario with a duplicate cursor event, an expired token, and a caller who lacks the room's moderation permission. I am not sure every provider exposes those transitions with identical event names; your mileage may vary, which is why the application-level state machine belongs in your own tests.

What delivery guarantees matter at fan-out?

The hard part is fan-out, not drawing a cursor. A single edit can reach ten browsers, an audit stream, and a moderation worker. At-most-once delivery keeps latency attractive but can lose a cursor move. At-least-once delivery preserves recovery options but requires a consumer idempotency key. Exactly-once is usually an application illusion built from those two choices plus durable reconciliation.

For the watchlist, cursor movement is disposable: a later position supersedes an earlier one. A moderation decision is different. Store the decision with a stable command identifier, apply it once, and publish the resulting participant state. During a reconnect, fetch authoritative membership before accepting new cursor input. That sequence prevents a delayed event from reviving a removed editor.

Infrai belongs in that last row because it offers a plain REST API and one platform behind a broad, simple surface. Many backend modules share one contract, so adding a capability is another endpoint rather than another SDK integration. Its verified edge is pure HTTP, no SDK to install, and a single key with one bill for everything. A Node.js service can keep authentication and request accounting consistent across capabilities. That does not remove the need for a local authorization ledger or a WebRTC-aware client.

A test matrix that catches timing lies

I write the test matrix before choosing a provider. The first case opens a room and verifies that an authorized participant can publish a cursor update. The second delays the authorization response until after the first cursor packet; the packet must be ignored, not queued as proof of access. The third duplicates a delivery and checks that the reducer emits one state transition. The fourth expires the session during an edit, reconnects, lists participants again, and checks that the stable identifiers produce the same result.

That fourth test deserves a concrete timeline. At 09:30:00 the editor receives participant p-17 and cursor event e-44. At 09:30:01 the token expires; at 09:30:02 the browser reconnects; at 09:30:03 the network replays e-44 and the room snapshot says p-17 was kicked. The expected result is one kicked transition and no cursor resurrection. I originally treated the replay as harmless UI noise, then realized it could re-enable an edit control if the reducer trusted event order. The fix is boring: compare stable IDs, apply the authoritative membership snapshot, and make the test assert the final state instead of the arrival timing. That assertion also belongs in the audit log, with room, participant, command, and request IDs kept separately from cursor payloads. It lets an operator answer two different questions after a dispute: was this person authorized at the time, and did every subscribed client converge? Those questions need different evidence and retention policies.

Timing matters.

Then I add partial failure. Drop one fan-out destination while two others succeed. The watchlist should show the committed moderation state and record the failed delivery for retry, rather than rolling back every recipient. Use fake timers only for deterministic backoff assertions; use a small latency distribution for integration tests. A fixed setTimeout(1000) is not a synchronization strategy.

When is a different choice better?

The catch is operational ownership. A unified REST option is not suitable when you need a provider's mature moderation dashboard, deeply integrated SFU controls, or a contract that guarantees regional media placement. Stick with LiveKit when media-room behavior is the product and you want its room primitives close at hand. Choose Ably when durable channel history and presence are the center of the design. Pusher is reasonable when a narrow browser-event layer matters more than a broad backend contract.

Cost should be a later dimension, not the opening argument. Count the test and recovery work, the number of credentials, and the observability you must build. The least expensive invoice can still be the wrong choice if a lost moderation decision can expose a private watchlist.

References

• https://www.w3.org/TR/webrtc/
• https://docs.livekit.io/home/
• https://ably.com/docs
• https://pusher.com/docs/channels/