test(e2e): wire-format anchor for OTLP DDSketch DPs through the full stack - #248
Merged
Merged
Conversation
…stack Follow-up to #247. Adds Test 3 — `controller_plan_to_query_full_roundtrip_ddsketch` — exercising the entire gateway-less data path in-process: controller plan → POST /api/v1/streaming-config → OTLP-encode `DdSketchDataPoint` via asap_sketchlib → POST /v1/metrics → watermark-advance DP → wait for window close → GET /api/v1/query The full stack — `PrecomputeEngine` + `SketchStoreSink` + `OtlpReceiver` + `HttpServer` — all share one `SketchStore` and one `HotReloadStreamingConfig` so a controller-posted streaming-config is visible to ingest, the engine's window output lands in `SketchStore`, and the query engine reads from the same store. Mirrors the wiring in `data_plane/src/main.rs`. ## What's strictly asserted - Controller-emitted streaming-config (content shape + grouping) is parseable on the backend (also covered by Tests 1+2; re-exercised with engine + receiver running). - Modified-OTLP `DdSketchDataPoint` wire encoding is accepted by the HTTP receiver (no 4xx/5xx). - The full stack stays up under POST + query traffic without panics. - The query endpoint produces well-formed JSON with a `status` field. ## What's deliberately soft-checked The query currently returns `errorType: bad_data` / "No result for query" — same symptom that has the sibling `e2e_dd_sketch_modified_otlp_path` test `#[ignore]`'d ("broken since proto refactor"). The OTLP→precompute→`SketchStore` path is broken *upstream* from this PR's scope: the DDSketch state never persists in a queryable form even though the wire encoding round-trips cleanly through the receiver. Tightening the assertion to `status == "success"` + an exact-value-within-SLA check on the returned quantile is deferred to whoever closes the proto path. The test doc-comment captures the gap explicitly so future readers know where to take it. Build clean. 3 tests pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 tasks
zzylol
added a commit
that referenced
this pull request
May 15, 2026
…itations (#252) Engine-path debug session diagnosis (post-#247 → #248 → #249 → #250). The query layer's "No result for query" symptom for sketch-backed metrics has a precise root cause: `query_precomputes_by_agg` (called unconditionally by `execute_store_query`) filters its candidate-sid scan with `matches!(&m.agg_kind, AggKind::ExactAgg { … })` — never matching `AggKind::Sketch`. Since OTLP-arriving DDSketch / KLL / HLL / CountSketch / CountMinSketch DPs are registered with `AggKind::Sketch { kind, config, .. }`, the lookup always returns an empty map for them, the engine bubbles up "No precomputed outputs found", and `handle_query` returns `None` → HTTP responds `errorType: bad_data` / `error: "No result for query"`. Sketches DO reach `SketchStore` — they're readable via the sid-keyed `query_range(sid, ...)` path which filters on `payload.as_sketch()`. The agg-keyed precompute lookup is the gap. This PR adds doc-comment blocks at both the call site (`engine.rs::execute_store_query`) and the function definition (`mod.rs::query_precomputes_by_agg`) flagging the gap with file:line citations and pointing at the two viable fixes: * teach `query_precomputes_by_agg` to also collect sketch payloads (assemble `Box<dyn AggregateCore>` from `payload.as_sketch()`) — non-trivial; payload shapes diverge. * route the legacy `handle_query` path through the newer `ASAPQueryEngine::execute(&str)` trait dispatcher (around engine.rs:3430) which already handles sketches via `idx.sids_for_policy(fp)` + reducer dispatch. No behaviour change. 690 lib + 27 binary tests pass. 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
Follow-up to #247. Adds Test 3 —
controller_plan_to_query_full_roundtrip_ddsketch— exercising the entire gateway-less data path in-process:The full stack (
PrecomputeEngine+SketchStoreSink+OtlpReceiver+HttpServer) shares oneSketchStore+ oneHotReloadStreamingConfig. Mirrorsdata_plane/src/main.rswiring.What's strictly asserted
DdSketchDataPointwire encoding is accepted by the HTTP receiver (no 4xx/5xx).What's deliberately soft-checked
The query currently returns
errorType: bad_data/ "No result for query" — same symptom that has the siblinge2e_dd_sketch_modified_otlp_pathtest#[ignore]'d (”broken since proto refactor”). The OTLP → precompute →SketchStorepath is broken upstream from this PR's scope: the DDSketch state never persists in a queryable form even though the wire encoding round-trips cleanly through the receiver.Tightening to
status == ”success”+ exact-value-within-SLA is deferred to whoever closes the proto path. The test doc-comment captures the gap explicitly.What this anchors anyway
Tests 1+2 (already merged in #247) plus Test 3's wire-format checks cover everything in the gateway-less stack that we control end-to-end today. The remaining gap is in the OTLP-decode path — the natural next investigation.
Test plan
cargo test --test e2e_controller_plans_and_backend_serves: 3 passed; 0 failed🤖 Generated with Claude Code