hive-c0re: split OpenAPI summary/description, move param docs to params
utoipa splits a handler's doc comment on the first blank `///` line: everything before it becomes the OpenAPI `summary` (shown in Swagger UI's collapsed endpoint-list row), everything after becomes the `description` (only shown once that row is expanded). With no blank line, the whole doc comment becomes the summary and the description is empty — which is what every handler in hive-c0re/src/dashboard/ was doing, so the all-endpoints list showed full multi-sentence prose next to every route instead of a short one-liner. For every `#[utoipa::path(...)]`-annotated handler across the 19 files in that module: - Inserted a blank `///` line after the first short sentence/clause so utoipa's split produces a real summary + description, where the doc comment had more to say. Left already-short single-clause docs alone (nothing to split). - Where a query struct derives `IntoParams`, moved param prose that duplicated a field's own doc comment out of the handler doc (the field already documents itself in the generated spec), or added a field doc where the handler explained a param that had none. No behavior changes — doc comments and `params()` description text only. Verified `cargo build -p hive-c0re` (clean) and `nix fmt` (zero changes) after. Closes #2969
This commit is contained in:
parent
c5fe61777e
commit
071dbd774c
16 changed files with 193 additions and 133 deletions
|
|
@ -30,7 +30,9 @@ pub(super) struct BuildLogsAllQuery {
|
|||
}
|
||||
|
||||
/// `GET /api/build-logs?limit=N` — most-recent build log headers across
|
||||
/// all agents, newest first. Same JSON shape as the per-agent endpoint.
|
||||
/// all agents, newest first.
|
||||
///
|
||||
/// Same JSON shape as the per-agent endpoint.
|
||||
#[utoipa::path(
|
||||
get,
|
||||
path = "/api/build-logs",
|
||||
|
|
@ -61,10 +63,10 @@ pub(super) struct BuildLogsQuery {
|
|||
}
|
||||
|
||||
/// `GET /api/build-logs/{agent}?limit=N` — most-recent build log
|
||||
/// headers for one agent, newest first. Returns
|
||||
/// `Vec<BuildLogHeader>` (JSON). Limit defaults to 10, server-side
|
||||
/// cap at 50. Backs the per-agent log chip in the agent card and
|
||||
/// the side-panel header list.
|
||||
/// headers for one agent, newest first.
|
||||
///
|
||||
/// Returns `Vec<BuildLogHeader>` (JSON). Backs the per-agent log chip
|
||||
/// in the agent card and the side-panel header list.
|
||||
#[utoipa::path(
|
||||
get,
|
||||
path = "/api/build-logs/{agent}",
|
||||
|
|
@ -102,9 +104,11 @@ pub(super) async fn get_build_logs_agent(
|
|||
}
|
||||
|
||||
/// `GET /api/build-logs/id/{id}` — full build log row (stdout +
|
||||
/// stderr concatenated) by id. Returns `BuildLogFull` (JSON), or
|
||||
/// HTTP 404 when the id doesn't exist (vacuum-reaped, or the
|
||||
/// operator passed a stale id from a refresh race).
|
||||
/// stderr concatenated) by id.
|
||||
///
|
||||
/// Returns `BuildLogFull` (JSON), or HTTP 404 when the id doesn't
|
||||
/// exist (vacuum-reaped, or the operator passed a stale id from a
|
||||
/// refresh race).
|
||||
#[utoipa::path(
|
||||
get,
|
||||
path = "/api/build-logs/id/{id}",
|
||||
|
|
@ -128,13 +132,15 @@ pub(super) async fn get_build_log_full(
|
|||
}
|
||||
|
||||
/// `GET /api/build-log/{node_id}` — the build log for a **queue node**,
|
||||
/// resolved node id → log-row id → full log. Same `BuildLogFull` JSON
|
||||
/// (`stdout` / `stderr` + header) as `get_build_log_full`; HTTP 404 when the
|
||||
/// node has no linked log (the client gates the request on
|
||||
/// `NodeView.build_log_id`, but a vacuum race can still 404). This is the
|
||||
/// on-demand live-log-panel fetch, distinct from the `build_log_id` on the
|
||||
/// wire — that id is for deep-linking to the BUILD L0GS tab's full history
|
||||
/// view, not for fetching the log content itself.
|
||||
/// resolved node id → log-row id → full log.
|
||||
///
|
||||
/// Same `BuildLogFull` JSON (`stdout` / `stderr` + header) as
|
||||
/// `get_build_log_full`; HTTP 404 when the node has no linked log (the
|
||||
/// client gates the request on `NodeView.build_log_id`, but a vacuum
|
||||
/// race can still 404). This is the on-demand live-log-panel fetch,
|
||||
/// distinct from the `build_log_id` on the wire — that id is for
|
||||
/// deep-linking to the BUILD L0GS tab's full history view, not for
|
||||
/// fetching the log content itself.
|
||||
#[utoipa::path(
|
||||
get,
|
||||
path = "/api/build-log/{node_id}",
|
||||
|
|
@ -201,14 +207,15 @@ struct BuildLogFrame {
|
|||
}
|
||||
|
||||
/// `GET /api/build-logs/id/{id}/stream` — SSE stream that delivers
|
||||
/// incremental stdout/stderr as a build runs. The client connects when
|
||||
/// it opens a running-build panel; the stream closes automatically once
|
||||
/// the build finishes (or the row disappears due to a vacuum).
|
||||
/// incremental stdout/stderr as a build runs.
|
||||
///
|
||||
/// Each frame is a JSON-serialised `BuildLogFrame`. The first frame
|
||||
/// always carries the full accumulated log so far (cursors start at 0);
|
||||
/// subsequent frames carry only new bytes. `done: true` on the final
|
||||
/// frame signals the browser to close the `EventSource`.
|
||||
/// The client connects when it opens a running-build panel; the
|
||||
/// stream closes automatically once the build finishes (or the row
|
||||
/// disappears due to a vacuum). Each frame is a JSON-serialised
|
||||
/// `BuildLogFrame`. The first frame always carries the full
|
||||
/// accumulated log so far (cursors start at 0); subsequent frames
|
||||
/// carry only new bytes. `done: true` on the final frame signals the
|
||||
/// browser to close the `EventSource`.
|
||||
#[utoipa::path(
|
||||
get,
|
||||
path = "/api/build-logs/id/{id}/stream",
|
||||
|
|
@ -308,7 +315,9 @@ pub(super) async fn get_build_log_stream(
|
|||
}
|
||||
|
||||
/// `GET /api/build-logs/id/{id}/raw` — full log as `text/plain` for
|
||||
/// download. Stdout and stderr are concatenated with a `--- stderr ---`
|
||||
/// download.
|
||||
///
|
||||
/// Stdout and stderr are concatenated with a `--- stderr ---`
|
||||
/// separator (same layout the JS side-panel renders). The
|
||||
/// `Content-Disposition` header triggers a browser download with a
|
||||
/// descriptive filename so the operator can save and share the log.
|
||||
|
|
|
|||
Loading…
Reference in a new issue