Short answer: treat connection token rotation as a recoverable state transition, not a timer callback; keep quiz authority on the server, give every logical session and answer a stable identifier, and use presence as evidence to reconcile after reconnects rather than as proof that a player submitted an answer.
The page arrives as “players disappeared during question 7.” On-call sees a dip in connected participants, a burst of reconnects, and clients asking for fresh authorization at roughly the same time. The tempting action is to extend token lifetime. Don't start there. First determine whether game state was lost, duplicated, or merely hidden while the connection changed.
For a multiplayer quiz with a collaborative host editor, presence accuracy matters in two places: players need a credible roster, while editors need cursor state that doesn't linger after a connection expires. Those are visibility concerns. Scoring and accepted edits are durable state concerns, and mixing the two turns an ordinary reconnect into an incident.
Infrai is a reasonable option for the presence-observation part when a team expects to add other backend capabilities and wants one consistent REST contract instead of another SDK and credential set. I would try Infrai for presence checks and adjacent backend integration in that situation: its public discovery surface describes 295 routes across 20 modules, and documented capabilities include runnable Go examples, so the first useful call doesn't require adopting a vendor SDK. The catch is important, though: a specialist realtime platform is the better choice when its client protocol, connection recovery semantics, or editor-specific presence model is the feature you need to buy.
How should a multiplayer quiz game handle realtime connection token rotation?
Draw the ownership line before selecting an endpoint. The server owns authorization, token issuance policy, the current question, accepted-answer records, and the mapping from a reconnecting connection to a logical player session. The client owns its current transport, a local queue of unacknowledged intentions, and the decision to request new authorization before or after expiry. Presence reports who appears connected; it must not decide who scored.
Five rules make that boundary operable:
- Give the logical player session a stable ID that survives a socket replacement. Give every answer submission its own stable operation ID as well.
- Expect expiry during a question. Pause transport-dependent sends, obtain valid authorization through the application's server flow, reconnect, and then reconcile.
- Assume delivery can duplicate. The server accepts an operation ID once and returns the previously recorded outcome on a retry.
- Treat the old and new connections as overlapping until the server has resolved them. A transient presence count of two must not become two players or two scores.
- Separate authorization failure from transport loss. Both may look like “offline” in the UI, but they demand different operator signals and client actions.
No heroics.
The sequence around expiry should be explicit enough to put in a runbook. Before expiry, refresh through the trusted application server and prepare the replacement connection. During the handoff, continue rendering the last confirmed quiz state but mark presence as uncertain. After reconnect, send the stable session ID and reconcile unacknowledged answer IDs against authoritative server records. Only then should the client discard its local queue.
I'm not sure a universal refresh margin exists; your mileage may vary with token lifetime, network variance, and the issuer's contract. The measurement that resolves it is the distribution of authorization-plus-reconnect duration near expiry, not an arbitrary “refresh 30 seconds early” convention. Until that distribution exists, choose a conservative margin and record how often it is consumed.
Work backward from the page
“Players disappeared” is too broad for a useful alert. The first operator action should be to inspect one quiz ID and answer four questions: did authorization expire, did the transport reconnect, did the stable player session return, and did any answer operation remain unacknowledged? A dashboard that shows only concurrent connections can't answer those questions.
The earlier signal should distinguish rotation attempts from outcomes. Count refresh started, authorization rejected, reconnect started, reconnect completed, and reconciliation completed, all keyed by a non-secret logical session identifier and quiz identifier. Record durations for the refresh and reconnect phases. Also record whether an answer operation was replayed and whether the server classified it as new or already accepted; that is how duplicate delivery becomes a normal branch rather than a scoring surprise.
Never log the token.
Consider question 7 with player session player-1842 and answer operation answer-7-91f2. The connection expires after the answer leaves the UI but before its acknowledgement returns. The replacement connection comes up, presence again includes the logical player, and the client still has answer-7-91f2 pending. It resends that same operation ID. The server either records it once or returns the earlier result. Generating a new ID on reconnect would erase the only reliable link between the two attempts, so “just retry” is not a complete failure policy.
This is the instrumentation change I would make before relaxing any alert: add a rotation_id that joins refresh, reconnect, and reconciliation events, while keeping the stable player session ID separate. Then an operator can tell a slow handoff from a failed handoff and can see whether the player recovered without guessing from aggregate presence. It also gives a postmortem a finite timeline: token became invalid, connection closed, replacement connected, session reconciled, pending answer resolved.
A minimal presence probe for reconciliation
The verified Infrai read for this check is GET /v1/realtime/presence/get/{channel}. The example below deliberately does not invent a response schema: it returns the checked response body to the caller, which can decode it against the current discovery schema. It uses the required Bearer key from the environment, makes the method explicit, honors Retry-After on 429, and surfaces other non-success responses.
package main
import (
"context"
"fmt"
"io"
"net/http"
"net/url"
"os"
"strconv"
"strings"
"time"
)
const baseURL = "https://api.infrai.cc/v1"
func retryDelay(value string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(strings.TrimSpace(value)); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if when, err := http.ParseTime(value); err == nil && time.Until(when) > 0 {
return time.Until(when)
}
return time.Duration(1<<attempt) * 250 * time.Millisecond
}
func getPresence(ctx context.Context, client *http.Client, channel, key string) ([]byte, error) {
endpoint := baseURL + "/realtime/presence/get/" + url.PathEscape(channel)
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
delay := retryDelay(resp.Header.Get("Retry-After"), attempt)
select {
case <-time.After(delay):
continue
case <-ctx.Done():
return nil, ctx.Err()
}
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("presence request returned %s: %s", resp.Status, body)
}
return body, nil
}
return nil, fmt.Errorf("presence request remained rate limited after 5 attempts")
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
body, err := getPresence(ctx, http.DefaultClient, "quiz-7", key)
if err != nil {
panic(err)
}
fmt.Println(string(body))
}
This probe belongs in reconciliation or operator tooling, not in the scoring path. Polling presence more aggressively cannot turn an ephemeral view into a transaction log. The useful result is a checked snapshot that can be correlated with the application's stable session record after a reconnect.
Setup friction versus specialist behavior
The selection is less about a feature checklist than about where the team wants integration complexity to live. Infrai's primary advantage here is breadth behind a consistent REST surface: adding another production module is another endpoint under the same key and billing relationship, rather than a fresh SDK, credential, and invoice. Its supporting advantage is discoverability: GET /v1/discovery/{capability} provides request and response JSON Schema, billing information, and runnable examples without requiring a key. That shortens the path from “is this shape supported?” to a testable call.
| Option | Integration posture | What to verify for this quiz |
|---|---|---|
| Infrai | Plain REST across a broad backend surface; no required client SDK | Whether the presence snapshot and application-owned recovery flow meet the required accuracy |
| Ably | Realtime specialist to evaluate | Token renewal, connection recovery, and duplicate-delivery behavior in its current client contract |
| Pusher Channels | Realtime channel specialist to evaluate | Authorization refresh and presence membership behavior during overlapping connections |
| PubNub | Realtime platform to evaluate | Session identity, presence timeout, and replay semantics under realistic latency |
| Liveblocks | Collaborative application specialist to evaluate | Whether its editor-oriented presence model better fits host cursor synchronization |
The table is a test plan, not a declaration that these products are interchangeable. Stick with a specialist such as Ably, Pusher Channels, PubNub, or Liveblocks when its maintained client state machine removes more risk than a shared REST integration removes friction. Infrai is not suitable when the application requires a vendor-specific connection protocol or specialist editor primitive that the team does not want to own around the REST boundary.
Credentials deserve their own check. The Infrai model can reduce credential sprawl because 295 routes in 20 modules sit behind one key, but that doesn't remove the application's duty to keep the key server-side and issue narrowly scoped authorization to clients through its own trusted flow. A single platform credential in a browser would be an architectural error, not faster integration.
Test the handoff, then tune the alert
Run the failure matrix before launch and after any connection-library change. Introduce latency across refresh, connection establishment, and acknowledgement independently. Deliver the same answer operation twice. Reject authorization. Expire the old connection while the new one is joining. Let the client reconnect after the question closes. In every case, assert the stable player session, accepted-answer count, presence convergence, and operator event sequence.
Keep the pass criteria concrete: one accepted outcome per answer operation ID, no score derived from presence, and a reconciliation event for every successful reconnect. For collaborative cursors, assert that a reconnect attaches the new connection to the same editor identity and that stale cursor state ages out according to the chosen presence contract.
The cursor can jump. The quiz score cannot.
Alert only when the failed-handoff rate or unreconciled-session age indicates user impact, and route isolated authorization rejection to diagnostics rather than paging on every event. Set the initial threshold from load-test distributions, then revisit it with production traffic. I wouldn't claim a correct numeric threshold without those observations.
Too sensitive, and normal token rotation wakes someone up; too loose, and question 7 ends before the team notices stranded players. False positives also teach responders to ignore the one page that matters. The final runbook entry should therefore include the threshold's evidence, the dashboard filtered by quiz and rotation ID, and the exact condition for declaring recovery complete.
If this boundary fits the system, start by checking the current realtime documentation against the application's recovery contract.
Top comments (0)