WebSocket vs SSE vs polling, reconnection with backoff and jitter, heartbeats, backpressure, message ordering, connection state UI, auth on upgrade, graceful degradation
94
98%
Does it follow best practices?
Impact
90%
1.87xAverage score across 5 eval scenarios
Passed
No known issues
{
"context": "Tests whether the agent chooses SSE over WebSocket for this one-way server-to-client use case, and proactively handles heartbeats, reconnection, connection state UI, and backpressure. The task does NOT mention transport choice criteria, reconnection, heartbeats, backpressure, or connection state. The agent should handle all of these proactively.",
"type": "weighted_checklist",
"checklist": [
{
"name": "sse-chosen-over-websocket",
"description": "SSE (EventSource) is chosen for this one-way server-to-client streaming use case rather than WebSocket. SSE is simpler, auto-reconnects, and works through proxies. The agent was NOT asked to justify the transport choice.",
"max_score": 14
},
{
"name": "heartbeat-configured",
"description": "Server sends periodic heartbeat comments (': heartbeat') to keep the SSE connection alive through proxies and load balancers. The agent was NOT asked about heartbeats.",
"max_score": 10
},
{
"name": "event-ids-for-resumable-stream",
"description": "SSE messages include an id: field so that EventSource sends Last-Event-ID on reconnection, enabling the server to replay missed events. The agent was NOT asked about event IDs or resumable streams.",
"max_score": 10
},
{
"name": "connection-state-ui",
"description": "Dashboard shows a visible indicator when the connection is lost or reconnecting. Uses role='status' or aria-live for accessibility. The agent was NOT asked about connection state.",
"max_score": 10
},
{
"name": "state-recovery-on-reconnect",
"description": "After reconnection, the client fetches the current metric snapshot or last 5 minutes of data rather than showing a gap in the charts. The agent was NOT asked about state recovery.",
"max_score": 8
},
{
"name": "backpressure-handling",
"description": "Server checks res.write() return value or tracks writableEnded to detect slow clients, and either skips messages or disconnects them rather than letting buffers grow unbounded. The agent was NOT asked about backpressure.",
"max_score": 8
},
{
"name": "client-cleanup-on-disconnect",
"description": "Server removes disconnected clients from its tracking data structures (listening for 'close' event on the response)",
"max_score": 6
},
{
"name": "graceful-degradation-to-polling",
"description": "Client falls back to polling if EventSource is not available or fails to connect. The agent was NOT asked about fallback behavior.",
"max_score": 6
},
{
"name": "sse-headers-correct",
"description": "SSE response includes correct headers: Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive, and optionally X-Accel-Buffering: no",
"max_score": 6
},
{
"name": "proper-cleanup-on-unmount",
"description": "React hook returns a cleanup function that calls EventSource.close() on unmount",
"max_score": 4
},
{
"name": "dead-client-detection",
"description": "Server detects and removes clients whose connections have ended (checking writableEnded or handling write errors) rather than accumulating dead client references. The agent was NOT asked about dead client detection.",
"max_score": 6
},
{
"name": "typescript-types-defined",
"description": "Metric data types are defined with TypeScript interfaces. No use of 'any'.",
"max_score": 4
}
]
}evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
skills
realtime-web-patterns
verifiers