Console: the worker's Events tab scrolls back through its history #911

Part of #906.

Scope

The worker page's Events tab shows that worker's kept history, back to its start or to the console's event cap, whichever comes first: MAX_EVENTS as the console has it when this lands (10,000 today; #917 makes it 1,000). It fills the page and loads older events as the operator scrolls, the way Activity does. To make that cheap on a gateway, GET /v1/events gains a worker filter, served from a new index on the history's events table.

In short

Today the Events tab shows the last hour of the events the console already holds, filtered in the browser, in a list that grows with the page. After this PR it is the same scrolling feed as Activity, holding only this worker's events. It asks the daemon for them 100 at a time, with GET /v1/events?worker=<workerId>&before=<eventId>&limit=100. Every read the tab's feed makes carries worker: the first since=1h, the gap after a stream reconnect, and each older page. At the cap the feed stops and its end row says Showing the newest <cap> events., as Activity's does. With none, the tab says No events for this worker yet. (today: No events for this worker in the last hour.).

flowchart LR
  T[Events tab] -->|"changed: ?worker=w1&limit=100"| G[GET /v1/events]
  T -->|"scroll near the end: ?worker=w1&before=id&limit=100"| G
  G --> H["history: only payload.workerId = w1 (changed)"]
  S[live event stream] -->|"filtered by workerId, as today"| T

The new query parameter:

"Worker id" here: the id GET /v1/workers gives a worker. "Payload workerId": the field a gateway adds to every event it takes from a worker.

If this goes wrong, a user would see another worker's events on the tab, or the tab stop scrolling back before the history's start.

Technical spec

Facts

Modules touched

Searches: rg "events.replay|replayPage|eventsPageQuery|eventsQuerySchema|useWorkerEvents|WorkerEventList|eventsOfWorker" over src, ui/src, e2e.

flowchart LR
  UI[ui: worker Events tab, data/event-feed, ds/feed.css *] --> R[http: GET /v1/events *]
  R --> C[contract: events.replay input *]
  R --> D[daemon dispatcher *]
  R --> GD[gateway dispatcher *]
  D --> H[history: replay, replayPage *]
  GD --> H

sequenceDiagram
  participant T as Events tab
  participant G as Gateway
  participant H as History
  T->>G: GET /v1/events?worker=w1&limit=100
  G->>H: replayPage({limit:100, workerId:"w1"})
  H-->>G: 100 envelopes with payload.workerId w1
  G-->>T: 200 {events}
  T->>G: GET /v1/events?worker=&limit=100
  G-->>T: 400 worker must be a worker id of 1 to 128 characters

Contract and event changes

events.replay input gains workerId?: string, 1 to 128 characters. This PR bumps the protocol by one. History: after the file has opened (not inside configureDatabase, whose throws count as damage and set the file aside, src/history/index.ts:301-337,366), the history runs CREATE INDEX IF NOT EXISTS events_worker ON events ((CASE WHEN json_valid(envelope) THEN json_extract(envelope, '$.payload.workerId') END), timestamp, seq) in its own try. The json_valid guard keeps a row of bad JSON from failing the build (a bare json_extract fails it with malformed JSON). A filtered read is WHERE (CASE WHEN json_valid(envelope) THEN json_extract(envelope, '$.payload.workerId') END) = ? AND json_extract(envelope, '$.event') <> 'worker.rejected', with the same cursor and order as today; EXPLAIN QUERY PLAN gives SEARCH events USING INDEX events_worker (<expr>=?), so it walks only that worker's rows. On an existing file the index is built once. The memory fallback filters the same way before cutting to limit. The HTTP query worker: a string of 1 to 128 characters, any characters; anything else gets 400 with the message above. No event changes.

Other code on the same state

The event history (events table, the bus's memory). Searched rg "replayPage|\.replay\(" src --glob '!*.test.ts' (20 hits; 3 are leasing's unrelated requests.replay): the two dispatchers (src/daemon/dispatcher.ts:842-846, src/gateway/dispatcher.ts:374-378), the history module (src/history/index.ts:71-220), the server's handle type (src/daemon/server.ts:150) and the test fake (src/history/testing.ts:116). simlock events reaches the same path through events.replay and sends no workerId, so it is unchanged. Reads only; nothing here writes. #905 changes how the console refetches event lists; whichever lands second keeps the other's behaviour.

Failure modes

No state written.

Rules in play

• ADR 0012 §1: "returns exactly one view: the worker itself" — on a worker, worker matches its own instance id only.
• ADR 0032 (event history is a SQLite database): the filter reads the existing table through one new index; no new table, column or projection.
• documentation rule 9 — website/src/content/docs/docs/reference/events.mdx:42-47 gains worker; console.mdx:126 lists the four tabs and says Events scrolls back through the worker's history.

Tests

Seams, one per line: src/http/app.test.ts (the route's refusals, fake dispatch), e2e/gateway-event-relay.test.ts (a real gateway and worker over HTTP, end to end), src/history/history.test.ts (the memory fallback), and e2e/console/workers.spec.ts:783 for the tab, extended.

• A caller sends a bad worker: empty or 129 characters → 400 worker must be a worker id of 1 to 128 characters; no worker → as today (app.test.ts).
• An operator pages a gateway's events by worker: worker=w1&limit=100 → only w1's events, oldest first; before=<id>&limit=100 → the next older page; since=1h → w1's last hour; a worker.rejected claiming w1 → absent; worker=nobody → none; on the worker itself, through its socket (a joined worker has no HTTP), events.replay with its own id → every event, another id → none (gateway-event-relay.test.ts, gateway and worker real).
• The history reads a worker's events without the database or the index: with no readable database, replayPage with workerId returns only that worker's events from memory, limit counted after the filter; an index build that throws is logged and the file is not set aside; a stored row of bad JSON does not fail the build (history.test.ts).
• An operator opens a worker's Events tab on a two-worker gateway: the feed fills the page below the tabs; scrolling near the end loads that worker's older events until the start row; the other worker's events never appear; a new event of the worker arrives at the top; with none, No events for this worker yet. (workers.spec.ts:783, extended).

Done when

• pnpm test, pnpm test:e2e e2e/gateway-event-relay.test.ts and pnpm test:console pass, with the four Tests lines above.
• website/src/content/docs/docs/reference/events.mdx documents worker; console.mdx lists the worker page's four tabs.
• The OpenAPI document lists worker on GET /v1/events (it is built from the declaration).

Out of scope

• A --worker flag on simlock events; a filter on the MCP tools.
• Changing the console's event cap.
• Activity's own filters.

Depends on

• The console reads per page through a query cache, and events mark data stale #914 (rewrites useWorkerEvents's reads, ui/src/state/workers.ts:185-191)
• The daemon says what needs the operator: GET /v1/inbox #915 (bumps the protocol; it already follows One lease is read directly, and gateway leases name the worker's lease id #913)
• One shared recent-events list per console tab #917 (splits ui/src/data/event-feed.ts into query functions and sets the cap)

This task's console half is built on what #914 and #917 leave: the Tests lines say what the tab does, not which class does it.

Written by an agent.