feat(sketch-db): GET /api/v1/db/schemas — §15.2 registry read API - #23
Merged
Merged
Conversation
Adds an HTTP endpoint that exposes the `SchemaRegistry` state to operators and the controller (design doc §15.2). Matches the per-`agg_id` lifecycle lifecycle view that the design doc promised: one row per schema with `agg_id`, `metric_name`, `status`, `created_at_ms`, `retired_at_ms`, `expires_at_ms`, and `aggregation_type`. Query param `?status=active|retired|expired|all` (default `all`) filters; unknown values return 400. When the HTTP server was built without `with_schemas` the endpoint returns 503 — same shape as the `/api/v1/streaming-config` endpoint without a hot-reload handle, so operators can probe capability. Entries are sorted by `agg_id` so the response ordering is stable across calls (and easy to diff from the CLI). Two integration tests cover: * two-aggregation lifecycle + `status` filter (active, retired, all, plus a 400 for a bogus filter), * 503 when no registry is attached. 561 lib tests pass; clippy/fmt clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
zzylol
added a commit
that referenced
this pull request
Apr 17, 2026
… API Companion to PR #23's `/api/v1/db/schemas`. Exposes `SchemaRegistry::timeline_for_metric` over HTTP so operators and external tooling can answer "which agg_id served this slice of history?" without attaching a debugger. Required params: `metric` (string), `start_ms` (u64 millis), `end_ms` (u64 millis). Missing or unparsable params return 400; unattached registry returns 503 (matches the schemas endpoint). Response includes per-segment `{agg_id, start_ms, end_ms, status, coverage}` — the same shape `timeline_for_metric` already returns to Rust callers. 3 new integration tests cover: * end-to-end reconfigure: two POSTs to `/api/v1/streaming-config`, then assert `timeline?metric=...&start=...&end=...` returns the retired + active segment pair (with a 5ms spacing between posts so neither schema ends up with zero-width ownership at ms resolution), * missing/malformed params → 400, * missing registry → 503. 570 lib tests pass (up from 567); clippy + fmt clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 tasks
zzylol
added a commit
that referenced
this pull request
Apr 17, 2026
… API (#25) Companion to PR #23's `/api/v1/db/schemas`. Exposes `SchemaRegistry::timeline_for_metric` over HTTP so operators and external tooling can answer "which agg_id served this slice of history?" without attaching a debugger. Required params: `metric` (string), `start_ms` (u64 millis), `end_ms` (u64 millis). Missing or unparsable params return 400; unattached registry returns 503 (matches the schemas endpoint). Response includes per-segment `{agg_id, start_ms, end_ms, status, coverage}` — the same shape `timeline_for_metric` already returns to Rust callers. 3 new integration tests cover: * end-to-end reconfigure: two POSTs to `/api/v1/streaming-config`, then assert `timeline?metric=...&start=...&end=...` returns the retired + active segment pair (with a 5ms spacing between posts so neither schema ends up with zero-width ownership at ms resolution), * missing/malformed params → 400, * missing registry → 503. 570 lib tests pass (up from 567); clippy + fmt clean. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
zzylol
added a commit
that referenced
this pull request
Apr 17, 2026
Operator + controller-facing HTTP surface for §10.2 backfill jobs.
Endpoints return a stable JSON shape so the DC controller can
POST jobs + poll progress without attaching a debugger, and the
`/jobs/:id` detail is the same data Phase 5f's coverage tracker
will consult.
## New endpoints
| Method | Path | Purpose |
|---|---|---|
| POST | `/api/v1/db/backfill` | Create a queued job. Body `{agg_id, start_ms, end_ms, source, windows_total}`. Returns 201 with `{job_id}`. |
| GET | `/api/v1/db/backfill/jobs` | List, optional `?status=queued|running|complete|failed|cancelled|all` filter. Sorted by job_id. |
| GET | `/api/v1/db/backfill/jobs/:id`| Detail (including `progress`, `windows_done`, timestamps, and any `error_message`). |
| DELETE | `/api/v1/db/backfill/jobs/:id`| Cancel non-terminal job. 200 on success, 404 unknown, 409 if already terminal. |
Consistent with the §15.2/§15.3 endpoints from PR #23 / PR #25:
- 503 when `HttpServer` wasn't built with `with_backfill_registry`.
- 400 on malformed body or inverted range.
- Response JSON tagged `{status: "success"|"error", ...}`.
## Wire-up
* `HttpServer` gains `with_backfill_registry()` alongside
`with_schemas()` / `with_hot_reload_config()`.
* `AppState` carries an `Option<Arc<BackfillRegistry>>` so each
handler can bail to 503 cleanly when the registry isn't
attached.
* `main.rs` always creates a fresh `Arc<BackfillRegistry>` and
attaches it — no CLI flag required. Without Phase 5e's worker
pool, jobs stay `Queued` forever but are still visible + can be
cancelled, which is useful shadow-mode for validating the DC
controller's REFRESH dispatch logic before the worker arrives.
## Test plan
- [x] 5 new integration tests:
* Full lifecycle: POST → GET one → GET list → GET filtered lists
(both `queued` matches and `running` is zero) → DELETE cancels
→ second DELETE is 409.
* POST with inverted range → 400.
* GET on unknown id → 404.
* All endpoints return 503 when no registry is attached.
* GET `jobs?status=junk` → 400.
- [x] 625 lib tests pass (up from 620).
- [x] clippy + fmt clean.
## Next phase
5e: real `WindowProcessor` that builds the target sketch from raw
samples and writes per-window precomputes into the store through
the §6.3 schema barrier. When 5e merges, POSTing a backfill job
will actually rebuild history.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
zzylol
added a commit
that referenced
this pull request
Apr 17, 2026
Operator + controller-facing HTTP surface for §10.2 backfill jobs.
Endpoints return a stable JSON shape so the DC controller can
POST jobs + poll progress without attaching a debugger, and the
`/jobs/:id` detail is the same data Phase 5f's coverage tracker
will consult.
## New endpoints
| Method | Path | Purpose |
|---|---|---|
| POST | `/api/v1/db/backfill` | Create a queued job. Body `{agg_id, start_ms, end_ms, source, windows_total}`. Returns 201 with `{job_id}`. |
| GET | `/api/v1/db/backfill/jobs` | List, optional `?status=queued|running|complete|failed|cancelled|all` filter. Sorted by job_id. |
| GET | `/api/v1/db/backfill/jobs/:id`| Detail (including `progress`, `windows_done`, timestamps, and any `error_message`). |
| DELETE | `/api/v1/db/backfill/jobs/:id`| Cancel non-terminal job. 200 on success, 404 unknown, 409 if already terminal. |
Consistent with the §15.2/§15.3 endpoints from PR #23 / PR #25:
- 503 when `HttpServer` wasn't built with `with_backfill_registry`.
- 400 on malformed body or inverted range.
- Response JSON tagged `{status: "success"|"error", ...}`.
## Wire-up
* `HttpServer` gains `with_backfill_registry()` alongside
`with_schemas()` / `with_hot_reload_config()`.
* `AppState` carries an `Option<Arc<BackfillRegistry>>` so each
handler can bail to 503 cleanly when the registry isn't
attached.
* `main.rs` always creates a fresh `Arc<BackfillRegistry>` and
attaches it — no CLI flag required. Without Phase 5e's worker
pool, jobs stay `Queued` forever but are still visible + can be
cancelled, which is useful shadow-mode for validating the DC
controller's REFRESH dispatch logic before the worker arrives.
## Test plan
- [x] 5 new integration tests:
* Full lifecycle: POST → GET one → GET list → GET filtered lists
(both `queued` matches and `running` is zero) → DELETE cancels
→ second DELETE is 409.
* POST with inverted range → 400.
* GET on unknown id → 404.
* All endpoints return 503 when no registry is attached.
* GET `jobs?status=junk` → 400.
- [x] 625 lib tests pass (up from 620).
- [x] clippy + fmt clean.
## Next phase
5e: real `WindowProcessor` that builds the target sketch from raw
samples and writes per-window precomputes into the store through
the §6.3 schema barrier. When 5e merges, POSTing a backfill job
will actually rebuild history.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GET /api/v1/db/schemas(design doc §15.2) returns the currentSchemaRegistrystate as JSON: one row per schema with agg_id, metric_name, status, created/retired/expires timestamps, and aggregation_type.?status=active|retired|expired|allfilters (defaultall). Unknown values → 400.HttpServerwas built withoutwith_schemas, matching the existing/streaming-configendpoint's missing-handle behaviour.Why
Operators and the controller currently have no way to inspect the registry without a debugger. This is the read-only half of the §15 controller-facing API surface — enough to answer "which aggregations exist, which are retired, and when do they expire?" from a curl.
Test plan
🤖 Generated with Claude Code