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.

The identity on a socket is fixed at upgrade time. Who the user is 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. (Their claims, by contrast, are refreshed while they stay connected; see Custom Claims.) The client SDK reconnects automatically after login()/logout() for exactly this reason, which fires close then open with the new identity.