WebSocket events

Sulu broadcasts launch and test-result updates over a STOMP-over-SockJS connection.

Connection

The frontend connects to /ws (SockJS) and authenticates with a JWT CONNECT frame: the client sends Authorization: Bearer <access-token> in the STOMP CONNECT native headers. WebSocket auth is separate from the REST Bearer JWT — the access token still travels on the CONNECT frame because SockJS cannot set custom request headers. Behind the scenes the backend relays over a RabbitMQ STOMP broker (/topic, /queue).

Subscription

Frontend subscribes to launch-level topics. Topic names are owned by the backend; the frontend client (SuluWebSocket) handles subscription bookkeeping.

Events

{
  "type": "TEST_RESULT_UPDATED",
  "launchId": 42,
  "testResultId": 99,
  "payload": { "status": "PASSED", "duration": 1240 }
}

Other types include TEST_RESULT_CREATED, LAUNCH_FINISHED, LAUNCH_CLOSED, LAUNCH_METRICS_UPDATED.

Delivery semantics

• At-most-once. The WebSocket is a notification channel, not the source of truth.
• The REST API is authoritative. UI state is reconciled with REST on page load and rehydrated as events arrive.

Reconnection

The SockJS client auto-reconnects with exponential backoff. The UI shows a LIVE pill in the launch header when the connection is active; the pill disappears on persistent disconnect.

Use cases

• Live launch progress in the UI.
• Live updates in the launches list (new launches prepended, per-card progress updated).
• Real-time triage — multi-user mark-pass/fail visible to other viewers within ~100 ms.