feat(sessions): add real-time session updates via server-sent events

[Lokimorty]

Summary

Implements push-based real-time updates for the Sessions page using Server-Sent Events. New sessions now appear instantly without manual reload or polling - updates only happen when actual session creation events occur.

Changes

• Added SSE event emitter and stream endpoint for session notifications
• Modified tracking endpoint to emit events when sessions are created
• Created useSessionStream hook to connect clients to the SSE stream
• Fixed LoadingPanel to prevent UI flicker during background refetches

Notes

This uses in-memory pub/sub, suitable for single-server deployments. Multi-server setups would need Redis pub/sub.

[vercel]

@Lokimorty is attempting to deploy a commit to the umami-software Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Overview

Greptile Summary

Implemented real-time session updates using Server-Sent Events with in-memory pub/sub pattern. When new sessions are created via /api/send, events are emitted and pushed to connected clients through SSE streams, triggering automatic UI updates.

• Added in-memory event emitter (session-events.ts) for pub/sub pattern
• Created SSE endpoint at /api/websites/{websiteId}/sessions/stream
• Modified tracking endpoint to emit session creation events
• Created useSessionStream hook to connect React components to SSE
• Fixed LoadingPanel to prevent UI flicker during background refetches

Critical Issue: SSE endpoint missing authentication - any unauthenticated user can access session data streams
Memory Leak: Empty listener sets never removed from in-memory map

Confidence Score: 1/5

• This PR has a critical security vulnerability - the SSE endpoint allows unauthorized access to session data
• Score reflects the missing authentication on the SSE endpoint (line 3-7 in route.ts), which is a critical security flaw. All other similar endpoints in the codebase use parseRequest and canViewWebsite checks. Additionally, there's a memory leak in the event emitter and missing error handling.
• Pay critical attention to src/app/api/websites/[websiteId]/sessions/stream/route.ts - must add authentication before merge

Important Files Changed

File Analysis

Filename	Score	Overview
src/app/api/websites/[websiteId]/sessions/stream/route.ts	0/5	new SSE endpoint missing authentication/authorization - critical security vulnerability
src/lib/session-events.ts	2/5	in-memory pub/sub with memory leak - empty listener sets never cleaned up
src/components/hooks/useSessionStream.ts	3/5	SSE client hook without error handling or reconnection logic

Sequence Diagram

sequenceDiagram
    participant Client as Browser Client
    participant UI as SessionsDataTable
    participant Hook as useSessionStream
    participant SSE as /sessions/stream
    participant Events as session-events.ts
    participant Track as /api/send
    participant DB as Database

    Client->>UI: Navigate to sessions page
    UI->>Hook: Initialize useSessionStream(websiteId)
    Hook->>SSE: GET /api/websites/{websiteId}/sessions/stream
    SSE->>Events: subscribeToSessions(websiteId, callback)
    Events-->>SSE: return unsubscribe function
    SSE-->>Hook: SSE connection established
    
    Note over Client,Track: User visits tracked website
    Client->>Track: POST /api/send (tracking event)
    Track->>DB: createSession(sessionData)
    DB-->>Track: session created
    Track->>Events: emitSessionCreated(websiteId, sessionId)
    Events->>SSE: invoke listener callback
    SSE->>Hook: SSE message with sessionId
    Hook->>UI: queryClient.invalidateQueries(['sessions'])
    UI->>DB: refetch sessions data
    DB-->>UI: updated sessions list
    UI->>Client: display new session
    
    Client->>UI: Navigate away
    Hook->>SSE: EventSource.close()
    SSE->>Events: unsubscribe()

Loading

[greptile-apps]

Additional Comments (3)

1. src/app/api/websites/[websiteId]/sessions/stream/route.ts, line 3-7 (link)

   logic: missing authentication and authorization - endpoint allows anyone to stream session updates without verifying they have permission to view this website

2. src/lib/session-events.ts, line 11-13 (link)

   logic: empty listener sets are never cleaned up from memory

3. src/components/hooks/useSessionStream.ts, line 10-14 (link)

   style: missing error handling - connection failures, network issues, or server errors will silently fail without retry or notification

_{7 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[Lokimorty]

Authentication: Added the missing parseRequest() and canViewWebsite() checks to the SSE endpoint. Now it properly validates permissions before streaming any session data (see stream/route.ts:12-22)

Memory leak: Fixed the listener cleanup logic. Empty sets are now removed from the map when the last listener unsubscribes (session-events.ts:18-20)

Error handling: Added try/catch blocks around JSON parsing with proper error logging (useSessionStream.ts:30-33)

Reconnection: Implemented exponential backoff that starts at 1s and caps at 30s (useSessionStream.ts:41-47)

[mikecao]

This is really nice, but the problem is that it won't work on Vercel or any other providers that use serverless to handle requests.

[Lokimorty]

I can see a few ways we can make it work:

1. Run the existing SSE endpoint on non-serverless infrastructure alongside Vercel. It's cheap and simple, but adds infrastructure to manage. And 10s polling as a fallback if sse fails — all serveless deployments will degrade gracefully
2. Third-party like Pusher or Ably that handles all the hard parts. It'll look something like this:

// Server: when session is created
pusher.trigger(`website-${websiteId}`, 'session-created', { sessionId });

// Client: subscribe to channel
const channel = pusher.subscribe(`website-${websiteId}`);
channel.bind('session-created', (data) => invalidateQueries());

and cost money, I think it's about the same with 200k messages/day = free, $50/1m messages, but creates external dependency. Self-hosting will probably have no real-time updates because of it (it'll just stay same as now)

3. Keep the 10-second polling. It's the simplest, but we poll even when there are no new sessions. More server load than SSE

I'm thinking the first makes most sense, it covers both self-hosted and serverless without external dependencies