feat(sketch-db): GET /api/v1/db/timeline — §15.3 schema timeline read API - #25
Merged
Merged
Conversation
… 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>
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>
3 tasks
zzylol
added a commit
that referenced
this pull request
Apr 20, 2026
…able stats (#48) Task #34 gap #1 of 3. The §7 schema-timeline primitive (`SchemaRegistry::timeline_for_metric`) and the cross-schema combiner (`engines::timeline_dispatch::combine_statistic`) landed in PRs #20 / #22 / #25, but `SimpleEngine::handle_query_promql` was still resolving a single `agg_id` via `resolve_agg_info_promql` and running the full query against it. A query whose time range spans a reconfigure boundary (old `agg_id` retired, new `agg_id` created) saw a data cliff for the pre-boundary slice. This PR wires the dispatcher: * New `SimpleEngine::try_handle_query_promql_via_timeline`: 1. Parse + pattern-match the query, extract metric name. 2. Build a probe `QueryExecutionContext` to read the resolved `[t1, t2]` + `Statistic`. 3. Call `timeline_for_query(metric, t1, t2)`. Bail out with `None` (fall-through to default single-agg path) if fewer than two segments, or if the statistic is non-combinable (quantile / topk / cardinality / rate / increase — those follow in PR B2 with a Partial HTTP response surface). 4. Per segment: reuse `build_query_execution_context_promql_for_agg_id` from PR #37 (the extracted forced-agg-id entry point), clip the store plan's `[start, end]` to the segment's bounds, execute, collect results. 5. Group by label-tuple and fold per-group per-segment scalars through `combine_statistic`. Emit the combined scalar as an `InstantVectorElement`. Purged segments or segments whose `agg_id` is no longer in the config go into `unresolved` so the combiner sees them. * `handle_query_promql` now tries the timeline path first; returns immediately on `Some`, falls through to the existing single-agg path on `None`. Zero behavior change when the timeline has 0–1 segments for the query's metric (the common case today). ## Scope Combinable stats only: Count / Sum / Min / Max. Non-combinable stats still take the single-agg path — PR B2 will surface `CombinedResult::Partial` on the HTTP response so users see `{covered, missing: [segments]}` explicitly instead of a silent data cliff. ## Validation - `cargo test -p query_engine_rust --lib` — 728 pass (baseline unchanged; the dispatcher stays dormant when tests only register one schema per metric). - `cargo clippy --all-targets -- -D warnings` — clean - `cargo fmt --all -- --check` — clean ## Follow-ups (explicit non-scope here) - **Integration test** seeding two agg_ids + cross-boundary Sum query. Requires the full `PrecomputeEngine` setup harness the existing e2e tests use; deferred as a dedicated PR so this one stays a focused dispatcher patch. - **PR B2**: Partial response surface for non-combinable stats on the HTTP adapter. 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
Companion to PR #23's
/api/v1/db/schemas. ExposesSchemaRegistry::timeline_for_metricover HTTP so operators can answer "which agg_id served this slice of history?" from a curl.metric,start_ms,end_ms.{agg_id, start_ms, end_ms, status, coverage}— same shape Rust callers already see./schemasbehaviour).Test plan
/streaming-configwith 5ms spacing, thentimeline?returns retired + active segment pair.🤖 Generated with Claude Code