Connection Triggers

Run server code when a client connects or disconnects using addConnectionTrigger:

Connection trigger handlers

// When a client connects
addConnectionTrigger("open", function (admin, sessionId) {
    // Record session start time
    update(["sessions", admin.uid, sessionId], {
        start: Date.now()
    });
});

// When a client disconnects
addConnectionTrigger("close", function (admin, sessionId) {
    // Record session end time
    update(["sessions", admin.uid, sessionId], {
        end: Date.now()
    });
});

Action Types

"open" - Fires when a client establishes a WebSocket connection
"close" - Fires when a client disconnects (browser close, network drop, or explicit close)

Callback Arguments

Your callback receives (admin, sessionId):

admin - The standard auth context object — see Auth Context for the full shape
sessionId - Unique ID for this WebSocket session

Note: Connection triggers fire for every WebSocket session, including unauthenticated visitors. Check admin.uid if you only care about logged-in users — the example above writes to ["sessions", admin.uid, sessionId], which for an anonymous visitor means admin.uid is undefined and the path is invalid.

A throwing handler is logged, not fatal. These run directly inside the socket's open/close callbacks, where an uncaught throw would end the process — not just the connection. The engine catches and logs instead. There is nothing to refuse at either point anyway: the socket is already open, or already closing.

admin is captured at upgrade time and never refreshes. The auth context is read once from the request's cookies when the WebSocket is established, so a user who signs in after connecting still shows as anonymous to that socket's triggers — and to its security rules. The client SDK reconnects automatically after login()/logout() for exactly this reason, which fires close then open with the new identity.