Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Events & Reactivity

Xenocept’s UI updates without polling. This page describes the actual event plumbing.

The Layers

There are two distinct event systems at play:

  1. AeorDB’s engine event bus (internal to AeorDB). Emits things like entries_created, entries_deleted, versions_created when the underlying store changes. This bus is fed by every write to the store.
  2. Xenocept’s session-event broadcast (Xenocept-specific). An internal channel emits created and dispatched events when a session is submitted or successfully dispatched.

The Xenocept frontend subscribes to layer 2 (/api/v1/sessions/events).

/api/v1/sessions/events

GET /api/v1/sessions/events

A Server-Sent Events stream. Each event is a JSON envelope with kind set to either created or dispatched and a sessionID field identifying the session.

The Sessions list UI subscribes at app startup and refreshes the list on every event.

/api/v1/channels/events

GET /api/v1/channels/events?name=<channel>

A separate SSE stream for the MCP channel-server bridge. xenocept --mcp <name> subprocesses subscribe to a single named channel; the frontend’s “Send to Channel” UI fires a POST /api/v1/channels/send that emits an event for the named channel only. The filtering is done in Xenocept itself via an mpsc registry keyed by channel name — it is not AeorDB’s path-prefix SSE filter, even though the surface effect is similar.

See MCP for the full channel-server flow.

If a consumer needs richer event metadata than kind + sessionID, the workaround is: subscribe to /api/v1/sessions/events, get notified, then call /api/v1/sessions/{id}/meta for the full session JSON.

Versioning, Strictly Speaking

AeorDB supports named snapshots and forks at the storage-engine level. Xenocept does not currently use those features for user-facing functionality. Submitted sessions are stored as a flat append-only collection under /sessions/{id}/ — there’s no “version this session” or “fork this session” operation surfaced to the UI.

The versions/snapshots AeorDB API is reachable from Xenocept’s backend code path, but no HTTP route exposes it to consumers. If Xenocept ever grows a “name a snapshot” or “fork a session” feature, this page is where it would land.