Workspace Presence: Detect Missed Realtime Messages and Refetch Authoritative State

Recovering who is online requires choosing between reconstructing an event history and replacing a stale view; for a marketplace auction workspace, replace the view whenever its sequence has a gap. TL;DR: track the last accepted sequence on the client, refetch authoritative state after a discontinuity, and report gap frequency. A connected socket alone doesn't establish that the displayed participant roster is current.

This addresses the usual Node.js and Express question about detecting missed realtime messages, but the important contract belongs to the application, regardless of the server framework. The preventative example below uses Go and makes no assumptions about undocumented message fields.

What page fired when the roster stopped being trustworthy?

For this review, I use a bounded, hypothetical production scenario: a seller and two bidders share an auction workspace, one bidder reconnects, and the roster still presents an earlier view of who is online. These are illustrative inputs, not a reported incident or a benchmark. The postmortem question is whether the client could distinguish a repaired roster from a socket that merely resumed receiving traffic.

Suppose the application last accepted sequence 41 and next observes 44. That discontinuity tells the client its view may be incomplete; it does not tell the client whether the skipped changes were three departures, repeated updates for one participant, or changes unrelated to membership. Guessing from the newest event makes the interface look decisive while discarding the evidence that it isn't.

Distrust the dashboard. A connection chart can look reassuring while a user makes a decision from stale state, so the useful operational question is: what page fired when recovery stopped completing? Gap frequency is a diagnostic signal; an unresolved recovery is the condition the application needs to make visible. An isolated, successfully repaired gap and repeated failures to obtain authoritative state deserve different responses.

The invariant is small: a client may present a roster as current only after establishing a trustworthy state boundary. Refetching the whole state is the recovery mechanism here. Recovering missing messages is a separate requirement.

How do sequence numbers detect missed realtime messages before a state refetch?

Sequence numbers need an application contract before they can detect anything useful. The following design assumes one ordered sequence domain for the workspace, contiguous numbers for the updates the client is entitled to receive, and an authoritative snapshot carrying the sequence through which its state is complete. Those are requirements for your application adapter, not claims about a vendor's response schema. A global counter that also includes hidden events would produce apparent gaps even when this client missed nothing.

Duplicates need a different treatment. Within that defined stream, a sequence at or below the last accepted value can be ignored; the next contiguous value can be applied; a larger jump invalidates the local view and starts recovery. After reconnecting, refresh even if no discontinuity has arrived. A silent connection supplies no next sequence against which to detect a missing final update.

The awkward part is the snapshot boundary. If a snapshot covers sequence 44 and event 45 arrives while the fetch is running, replacing local state and discarding that event can leave the client behind immediately. Serialize the transition or buffer incoming events, install the snapshot and its sequence together, discard buffered events already covered by it, then accept only a contiguous suffix. Another gap means another recovery attempt. Bound the buffer; if it overflows, invalidate and refetch instead of pretending that a partial buffer is complete. Consider a second overlap: a snapshot covers 46, while the buffer contains 45 and 47. Applying 45 would move backward through already represented work; dropping both entries would lose the update after the snapshot. The boundary determines which entry survives. These numbers are worked examples of the proposed application contract, not observed service behavior, and the implementation must preserve the same rule even when several refresh requests finish out of order.

Keep the roster uncertain until this finishes.

This approach favors convergence on present state over reconstruction of every transition. That is a useful trade for showing who is online. It would be inadequate as the sole record of accepted bids, payments, or an audit trail, where the missing transitions themselves may matter and need a durable application record.

Compare recovery work before choosing a transport

The useful comparison is how much of that recovery boundary your application must own, and how the result reaches the person carrying the pager. Product names alone don't settle it.

Infrai uses one key, one bill, and one REST API for 295 routes across 20 modules. Realtime and observability share one API key: adding diagnostic access means another HTTP request rather than another SDK integration. No SDK is required. Public discovery includes request and response schemas, which helps establish the adapter boundary without guessing fields. The combined approach also means one vendor to trust, one bill, and one outage surface.

That trade-off matters.

The limitation of a combined backend is the shared dependency: it is not suitable when the application's operational policy requires monitoring and delivery to use separate vendors. Choose the Pusher Channels plus Datadog arrangement in that case, accepting the additional credentials and integration work for the separation you require.

For the two-service alternative, the glue is concrete: assign the workspace sequence in application code, detect discontinuities at the consumer, record the repair outcome, and send the relevant diagnostic context to monitoring with its separate credentials. Decide whether you want that separation. Don't turn fewer credentials into an unmeasured uptime claim.

The code below demonstrates the narrower, verifiable handoff: inspect a realtime channel, use its successful response as the trigger for a metrics query, and return both outputs together for diagnosis under the same key and base URL. It does not claim that a channel description is an authoritative participant snapshot or that a metrics query records a new gap measurement. Your application must supply those state and reporting contracts.

Put the preventative check ahead of diagnostic collection

Here is a runnable Go program using only the standard library. Set INFRAI_API_KEY, INFRAI_BASE_URL to the documented versioned API base, and WORKSPACE_CHANNEL in the environment, save it as main.go, and run it with Go. The sequence values are local demonstration inputs: they are not vendor response fields. The program detects the illustrative 41-to-44 gap, requests channel information, then feeds that result into a diagnostic function that queries metrics and emits both responses. Neither read mutates application state.

package main import ( "context" "encoding/json" "fmt" "io" "net/http" "net/url" "os" "strconv" "time" ) type api struct { key string baseURL string client *http.Client } func (a api) get(ctx context.Context, path string) (json.RawMessage, error) { for attempt := 0; attempt < 3; attempt++ { req, err := http.NewRequestWithContext(ctx, http.MethodGet, a.baseURL+path, nil) if err != nil { return nil, err } req.Header.Set("Authorization", "Bearer "+a.key) resp, err := a.client.Do(req) if err != nil { return nil, err } body, readErr := io.ReadAll(io.LimitReader(resp.Body, 4<<20)) resp.Body.Close() if readErr != nil { return nil, readErr } if resp.StatusCode == http.StatusTooManyRequests && attempt < 2 { delay := time.Second * time.Duration(1<<attempt) retry := resp.Header.Get("Retry-After") if seconds, err := strconv.Atoi(retry); err == nil && seconds >= 0 { if d := time.Duration(seconds)*time.Second; d > delay { delay = d } } else if date, err := http.ParseTime(retry); err == nil { if d := time.Until(date); d > delay { delay = d } } timer := time.NewTimer(delay) select { case <-ctx.Done(): timer.Stop() return nil, ctx.Err() case <-timer.C: continue } } if resp.StatusCode < 200 || resp.StatusCode >= 300 { return nil, fmt.Errorf("GET %s: status %d: %s", path, resp.StatusCode, body) } if !json.Valid(body) { return nil, fmt.Errorf("GET %s: invalid JSON", path) } return json.RawMessage(body), nil } return nil, fmt.Errorf("retry limit reached") } func inspect(ctx context.Context, a api, channel json.RawMessage) error { metrics, err := a.get(ctx, "/metrics/query") if err != nil { return err } return json.NewEncoder(os.Stdout).Encode(struct { Channel json.RawMessage `json:"channel_response"` Metrics json.RawMessage `json:"metrics_response"` }{channel, metrics}) } func run() error { key, workspace := os.Getenv("INFRAI_API_KEY"), os.Getenv("WORKSPACE_CHANNEL") baseURL := os.Getenv("INFRAI_BASE_URL") if key == "" || workspace == "" || baseURL == "" { return fmt.Errorf("set INFRAI_API_KEY, INFRAI_BASE_URL, and WORKSPACE_CHANNEL") } last, incoming := uint64(41), uint64(44) if incoming <= last { return nil } if incoming-last == 1 { return nil } fmt.Fprintln(os.Stderr, "sequence gap: invalidate roster and request authoritative state") ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) defer cancel() a := api{key: key, baseURL: baseURL, client: &http.Client{Timeout: 10*time.Second}} channel, err := a.get(ctx, "/realtime/channel/get/"+url.PathEscape(workspace)) if err != nil { return err } return inspect(ctx, a, channel) } func main() { if err := run(); err != nil { fmt.Fprintln(os.Stderr, err) os.Exit(1) } } 

The two reads use one client configuration. The metrics request sends no invented filter parameters, and the resulting JSON preserves the channel response rather than assuming undocumented properties inside it. This is an on-demand diagnostic path, not a metrics polling loop. It also isn't a browser credential pattern: keep the service key on the server.

The three attempts, 10 seconds per request, 30 seconds overall, and four-megabyte response limit are example operating bounds, not service guarantees. Rate limiting uses exponential backoff and honors a longer Retry-After; a retry delay that exceeds the overall deadline ends the operation. Successful diagnostics must never be the prerequisite for beginning roster recovery, so a production integration should start the authoritative refetch independently of this inspection path.

The intentionally separate state adapter matters. Without a verified snapshot schema and its sequence boundary, attaching a field named sequence to an arbitrary channel response would create a copyable mistake. Define the roster snapshot in the application that owns membership, then install it through the buffered recovery procedure above.

Page on failed repair, and know when to use a different design

Report gap frequency with a denominator, such as gaps per observed update, and track reconnect-triggered refreshes separately. Otherwise a busy auction can look worse solely because it produces more traffic. Track whether recovery completes and how long the roster remains uncertain; a rate chart alone can't establish whether anybody is still looking at stale membership. Choose alert thresholds from the workspace's tolerance for uncertainty rather than borrowing an unexplained number from a sample.

No dashboard repairs state.

Full-state refetch is the preferred default here because the job is to show the current workspace membership. If the roster is too large to replace within the application's recovery budget, partition the state or evaluate a recovery protocol with explicit retention and replay boundaries. If every transition must be retained, use a durable history. Neither an online badge nor a gap counter should decide whether a bid was accepted.

Sources

References for evaluating transport recovery, monitoring integration, and the distinction between a realtime transport standard and an application state contract:

• Pusher Channels documentation
• Datadog API authentication
• Ably connection state and recovery
• Socket.IO connection state recovery
• W3C WebRTC 1.0