Skip to main content

Module admin

Module admin 

Source
Expand description

Admin web UI: a single signed-in /admin dashboard that consolidates the admin actions (service registry, background jobs, system health, settings, API docs, and “add a corpus”) which previously sprinkled the public homepage. Access uses the lightweight token scheme — an AdminSession cookie (frontend::actor), set on the sign-in page below.

Structs§

ActivityMessageDto
One recent conversion message (fatal/error/warning) for the LiveActivityDto stream — read from the log_* rows the dispatcher’s finalize thread already persists, joined to the task’s entry/corpus/service. The live signal of a run’s health.
AdminStatusDto
At-a-glance operational snapshot for the admin live ops console — the small-table signals (plus the one pending-task backlog count) the dashboard polls every few seconds and renders server-side on first paint. Every field is best-effort: a database hiccup degrades it to 0/None rather than failing the screen. Deliberately excludes the dispatcher-port / corpus-storage probes (those are the System Health screen’s job — and too slow to poll). Agents get this same snapshot from the token-gated GET /api/status (api_status) or the Prometheus gauges at /metrics.
FleetWorkerDto
One worker’s live activity row for the LiveActivityDto fleet feed — the “what the fleet is doing now” signal, read straight from the worker_metadata rows the dispatcher already keeps.
LastRunDto
The latest run’s headline, with live task tallies overlaid while it is still open (so the card shows real progress, not a frozen-at-completion zero).
LiveActivityDto
The admin live activity feed: the actively-converting fleet plus the most recent conversion problems. Every field is read-only over data the dispatcher already writes to Postgres as its normal work — the frontend polls it and the dispatcher is never in the request loop, so a slow or absent UI can never back-pressure or endanger the conversion hot path.
LoginForm
The sign-in form fields.

Functions§

admin_login
Processes sign-in (POST /admin/login): validates the token against auth.rerun_tokens; on success opens a server-side session and sets the ADMIN_COOKIE cookie to its random opaque id (HttpOnly, SameSite=Lax) — the cookie no longer carries the token — then redirects to the validated next destination (default /admin). A bad token (or a DB hiccup opening the session) returns to the sign-in page flagged, preserving next.
admin_login_page
The sign-in page (GET /admin/login?<bad>&<next>): a form to enter an admin token, plus a “sign in with a passkey” affordance when passkeys are enabled. ?bad=true flags a failed previous attempt; ?next= is the destination to return to after signing in (carried through the form).
admin_logout
Signs out (POST /admin/logout): revokes the server-side session (so the id is dead even if the cookie lingers), clears the cookie, and returns to the sign-in page.
admin_logs_feed
GET /admin/logs.json — the live-activity panel’s poll feed: the LiveActivityDto as JSON. Cookie-gated (a signed-in AdminSession); an expired session returns 401 so the page keeps its last-good values. The agent twin is api_logs (GET /api/logs).
admin_page
The admin dashboard (GET /admin): the consolidated home for admin actions. Signed-in admins only — an unauthenticated browser is redirected to the sign-in page (Err(Redirect)).
admin_status
Gathers the AdminStatusDto over one pooled connection (plus the in-memory pool counters). Shared by the HTML dashboard’s first paint and the /admin/status.json poll feed so both show identical state. Mostly cheap small-table reads (plus the one tasks_todo backlog count) — no dispatcher/storage probe.
admin_status_feed
GET /admin/status.json — the live ops console’s poll feed: the AdminStatusDto as JSON, for the dashboard’s few-second auto-refresh. Cookie-gated (a signed-in AdminSession); an expired session returns 401 so the page simply keeps its last-good values rather than redirecting an XHR. Same-origin only — the agent twin (token-gated, same DTO) is api_status (GET /api/status); the Prometheus gauges are at /metrics.
api_logs
GET /api/logs — the agent twin of the dashboard’s /admin/logs.json feed: the live fleet activity plus the most recent fatal/error conversion messages as one structured JSON call a monitoring agent can poll. Token-gated via the Actor guard.
api_status
GET /api/status — the agent twin of the dashboard’s /admin/status.json feed: the AdminStatusDto system snapshot (corpus count, the worker fleet, background-job activity, the pending-conversion backlog, and the latest run) as one structured JSON call a monitoring agent can poll. Complements the Prometheus /metrics gauges — it carries the structured last_run detail (owner / description / timing) the gauges can’t, and matches cortex status --json. Token-gated via the Actor guard (401 without a valid token).
live_activity
Gathers the LiveActivityDto over one pooled connection. Like admin_status, every read is best-effort (degrades to an empty list) and read-only — the dispatcher is never involved, so the live feed cannot perturb the conversion hot path.
routes
The route set for the admin web UI.