Module services 

Services capability: the worker-fleet view for a service, as a human screen + agent API.

Follows the symmetry contract — the worker-fleet screen (GET /workers/<service>) and its agent twin (GET /api/services/<service>/workers) live in one module, both pooled (no per-request Backend::default()). The agent twin surfaces the per-worker dispatch/return tallies and the in-flight backlog, the operational signal for spotting a stuck or struggling worker (directly useful for watching the hardened dispatcher’s fleet).

Structs

ActivateOnCorpusForm

Fields of the per-service “Register on a corpus” form: the single corpus (a <select> choice over existing corpora) to activate this already-defined service on.

AddServiceForm

Fields of the “Add a service” form: the new-service definition plus the names of the corpora (zero or more checkboxes) to activate it on.

DeleteServiceForm

Fields of the human “Delete service” form: the service name echoed as confirmation.

LeaseUpdateRequest

Request body for setting a service’s per-service lease timeout (D-17).

RuntimeBucketDto

One bar of the runtime-distribution histogram: a millisecond range and how many conversions fell in it.

RuntimeRowDto

One conversion’s recorded wall-time (from the worker’s Info:runtime_ms:<N> log line), for the slowest-conversions table.

ServiceDto

A registered service as exposed over the API/UI — the service-registry view. name is the stable external handle used by every service route.

ServiceRegisterRequest

Request body for registering (defining) a new service.

ServiceRuntimeDto

The per-service conversion-runtime report: a distribution summary, an aggregate histogram (the bar chart), and the paginated slowest conversions. Sourced from the worker’s Info:runtime_ms:<N> log lines, so it only populates after a run with a runtime-emitting worker. Heavier than the other service views (it scans log_infos), hence its own page.

SetLeaseForm

Fields of the registry screen’s inline “set lease” form. A blank value parses to None (clear).

WorkerDto

A worker’s dispatch/return tallies for a service — the machine-readable fleet-health view.

Functions

activate_on_corpus_human

Activates an existing service on the chosen corpus — a background service_activate job (the operator tracks it on /jobs). Gated by the signed-in AdminSession cookie (anonymous → sign-in). Redirects to /jobs. 404 on an unknown service/corpus. (The agent twin is POST /api/corpora/<c>/services/<s>.)

activate_on_corpus_page

The “register an existing service on a corpus” screen: a <select> over the corpora this service is not yet activated on (already-activated corpora are excluded — re-activating is destructive). Signed-in admins only (anonymous → sign-in). 404 if the service is unknown.

add_service_page

The “Add a service” screen (GET /services/new): the full new-service form + a checkbox list of corpora to activate it on. Signed-in admins only (anonymous → sign-in). The agent equivalent composes POST /api/services (define) + POST /api/corpora/<c>/services/<s> (activate) per corpus.

api_service_runtimes

Conversion-runtime report for a service (agent twin of the runtime screen): distribution summary

api_service_workers

The worker-fleet status for a service (agent twin of the workers screen): per-worker dispatch/ return tallies and in-flight backlog. 404 if the service is unknown.

api_services

The service registry (agent twin of the registry screen): every registered service. 503 if the pool is exhausted.

create_service_human

Defines a new service and activates it on each checked corpus — one background activation job per corpus (each creates a TODO task per imported document, so a large corpus can run for a while; the operator tracks them on /jobs). Gated by the signed-in AdminSession cookie (anonymous → sign-in). Redirects to /jobs when any corpus was selected (so the in-flight registrations are immediately visible), else back to /services. 409 if the name already exists.

delete_service

Permanently deletes a service and all of its tasks + log messages across every corpus — the destructive twin of register_service, closing the R-6 orphan hazard at the data layer (Service::destroy). Token-gated via the Actor guard (an unauthenticated wipe must not be possible — 401 without a valid token) and double-guarded: the caller must echo the service name via ?confirm=<service>. The magic init/import services are infrastructure and can never be deleted (403). Returns 204 on success, 400 if the confirmation doesn’t match, 403 for a protected service, 404 if unknown.

delete_service_human

The human twin of delete_service: the registry screen’s per-service “Delete” form. Gated by the signed-in AdminSession cookie (anonymous → sign-in) and confirmation-gated (echoes the service name), then redirects back to /services. 400 if the confirmation doesn’t match, 403 for a protected service, 404 if unknown.

register_service

Registers (defines) a new service in the registry — the agent twin of the “Add a service” screen (/services/new, create_service_human). Token-gated via the Actor guard; 401 without a valid token, 409 if the service name already exists, 201 with the service on success. (This defines a service; activating it on a corpus — creating tasks — is POST /api/corpora/<c>/services/<s>.)

routes

The route set for the services capability (registry + worker-fleet, screens + agent API).

service_runtimes_page

The conversion-runtime screen for a service (HTML twin of api_service_runtimes): the aggregate runtime histogram (bar chart) + the paginated slowest conversions, reached from the worker screen. Signed-in admins only (anonymous → sign-in). Separate from the worker view because it reads the task_runtimes rollup. 404 if the service is unknown.

services_page

The service-registry screen (HTML twin of api_services): the table of registered services, each linking to its worker-fleet view. Signed-in admins only (an unauthenticated browser is redirected to the sign-in page; the agent twin keeps the token guard). 503 if the pool is exhausted.

set_service_lease

Sets (or clears) a service’s per-service lease / visibility timeout — the agent twin of the registry screen’s inline “lease” form (D-17). Token-gated via the Actor guard (401 without a valid token); 400 if seconds is non-positive, 404 if the service is unknown, 200 with the updated ServiceDto on success. null clears the override (the service falls back to the global dispatcher lease). Takes effect on the next dispatch — an already-leased task keeps the timeout captured when it was leased.

set_service_lease_human

The human twin of set_service_lease: the registry screen’s inline per-service lease form. Gated by the signed-in AdminSession cookie (anonymous → sign-in). A blank value clears the override; a non-positive value is 400. Redirects back to /services; 404 if unknown.

worker_report_page

The worker-fleet screen (HTML twin): the dispatcher’s registered workers for a service and their activity. Signed-in admins only (unauthenticated → sign-in page). 404 if the service is unknown. Relocated from bin/frontend.rs onto the pooled library surface.