refactor(query): remove ASAP_THANOS_QUERY_URL and the archive tier

[milindsrivastava1997]

Closes #746.

ASAP_THANOS_QUERY_URL was the only switch that built a ThanosQueryEngine, and nothing in the repo set it — no compose file, CI config or script. The forwarder never ran; the archive slot always held NoDataArchiveEngine, which answers instant queries with an empty-but-successful result. So every archive routing decision quietly returned "no data" where the Prometheus fallback would have returned a real answer.

Removing just the flag would have stranded ~1.2k lines reachable only from their own tests, so this removes the archive tier from the query path: 20 files, +668 / −2967.

---

Scoping Q&A

当前决策层级

层级	核心决定	对应问题	当前状态
1. 目标	停用 Thanos 和 Gorilla merger 的归档路径	Q1、Q4、Q5	两者的代码和入口均已删除
2. 查询行为	ASAP 无法处理时，按入口回退到 Prometheus、VictoriaMetrics 或 ClickHouse	Q6、Q7、Q9	三个入口分别实现；PromQL 回退仍需启用 --forward-unsupported-queries
3. 路由契约	不再生成或接受 thanos_query；删除归档引擎、存储类型和占位引擎	Q2、Q3、Q8、Q10、Q11	已实现；即时和范围查询的 NoEngineRegistered 现在都返回 503
4. 交付验证	按依赖顺序提交，运行相应测试	Q12、Q13	PR 现有 9 个提交；描述中的提交列表和验证数字仍停留在较早版本

Scoped by interview before any code was written. Each question, the evidence behind it, and the answer:

Q1. Delete ThanosQueryEngine entirely, or only the env-var wiring?

Outside the env wiring, the engine was built only by 4 tests in http.rs; thanos_query_engine/forward.rs was ~1.2k lines. Removing only the env var would have left it as dead code.

→ Delete entirely: the module, its re-exports, the 4 mock-Thanos tests, the main.rs registration, and the doc comments pointing at it.

Q2. Keep the "thanos_query" engine ID? (superseded by Q10/Q11)

The ID was a wire contract, not just an engine name: the control plane emitted it in routing plans, StorageBackend::GorillaObjectStore mapped to and from it, NoDataArchiveEngine registered under it, clients selected it via X-ASAP-Engine / ?engine=, and ~10 HTTP tests asserted data_source: thanos_query.

→ Originally "keep it", then reversed once the archive routing itself went (Q10/Q11).

Q3. Keep or remove ASAP_REQUIRE_ARCHIVE_ENGINE?

With Thanos gone it only chose between the empty-result stub and no engine (503 NoEngineRegistered). Nothing in the repo set it.

→ Remove it. Re-examined once more when it turned out the flag interacts with the Prometheus fallback:

• Instant queries: router-dispatched queries got Ok(empty) from NoDataArchiveEngine::execute, so the fallback was never reached. process_via_router had no fallback call even on NoEngineRegistered, so the flag didn't route those to Prometheus either.
• Range queries: the stub never implemented execute_range (trait default = CapabilityMiss), so range misses already reached the Prometheus fallback.

Decision unchanged; nothing set it, so no behaviour changed.

Q4. The Gorilla merger's read path depends on ThanosQueryEngine. Proceed?

gorilla-merger/ (Go) and GORILLA_MERGER_DESIGN.md planned for cold reads to go backend → ThanosQueryEngine → thanos-query → merger StoreAPI + S3. The design's own cleanup step said "set ASAP_THANOS_QUERY_URL".

→ Proceed; that direction is shelved. The design doc now records that its backend read path is removed and names the commit to restore the engine from.

Q5. Keep or remove the archive routing itself?

With only the stub in the slot, Exact → archive-only, ASAP CapabilityMiss → archive failover and the warm-retention range split all produced empty results that looked successful. The surface: the policy table, RangeTier + execute_range* tier variants, classify_range_tier, the X-ASAP-Accuracy header, the two resolve_metric_storage overrides, the ASAP engine's never-wired warm/archive stitch, the never-incremented cold counters, the control plane's thanos_query target, and ~40 tests — ~2–2.5k lines, ~70% tests.

→ Remove it.

Q6. What serves a query the ASAP tier can't answer, once there's no archive?

→ The Prometheus fallback when --prometheus-server is configured, otherwise the adapter's unsupported-query response. This is what the approximate SketchStore instant path already did and what range misses effectively did. Today's silent empty instant results become real answers.

Q7. What does X-ASAP-Accuracy: exact mean now?

Its only effect was routing: Exact skipped the sketch tier for the archive. (AccuracyTarget::Exact elsewhere — ClickHouse accelerator, control-plane planner — is unrelated and stays.)

→ Keep the header; exact now means "skip the sketch tier, go straight to Prometheus". Preserves the caller contract, keeps validation and the 400 on typos.

Q8. Should the control plane stop emitting thanos_query targets?

build_routing_entry gave every metric an asap_query default plus a thanos_query target claiming histogram_quantile, delta, deriv, absent, rate_post_hoc, plus topk (no CountSketch) and count (no HLL/CMS).

→ Stop emitting it. Those shapes now miss on the ASAP tier and go to Prometheus — same destination, minus the pretend hop. asap_tier_native_shapes stays; it's informational.

Q9. What about the two archive overrides in resolve_metric_storage?

Both existed so a query the sketch tier can't answer would reach the router instead of dying on the direct sketch path: topk with no heap-bearing sid, and sum_over_time over counter deltas (#301, where ExactAgg(Sum) sids can't reconstruct Σ-of-cumulative-samples). They were workarounds for the direct path having no fallback — exactly what Q6 now provides.

→ Delete both and their helpers. ⚠️ #301's fix now depends on --prometheus-server; see below.

Q10. Delete NoDataArchiveEngine, and what about GorillaObjectStore / "thanos_query"?

→ Delete the stub, with_archive_query_engine and the main.rs block — and remove the StorageBackend::GorillaObjectStore variant, ENGINE_ID_THANOS_QUERY and its CANONICAL_QUERY_ENGINE_IDS entry. Supersedes Q2.

Q11. How should the backend treat a thanos_query target in an incoming plan?

parse_engine_string errors on unknown engines, and that error rejects the whole routing document — so a control plane still emitting the target would have its plans refused.

→ Hard-reject, same as any unknown engine. No legacy-skip path: there are no production deployments, so deploy order isn't a concern.

Q12. How does this land?

→ One PR, commits in dependency order, each building and passing tests on its own.

Q13. Which e2e suites gate this?

→ The full data_plane/tests suite, not just the two in the blast radius.

---

Commits

Review commit by commit; each is independently green.

1. 8f829f6d delete the Thanos forwarder + both env vars (Q1, Q3, Q4)
2. 3d3e3223 remove data-plane archive routing — policy table, RangeTier, accuracy header, the two overrides (Q5, Q6, Q7, Q9)
3. 8f666c01 control plane stops emitting archive targets (Q8)
4. f2ab3105 remove the archive engine slot: stub + the ASAP engine's never-wired warm/archive stitch (Q10)
5. 197b816e drop the GorillaObjectStore axis and thanos_query id (Q10, Q11)
6. 2e433dcf delete dead cold counters, refresh stale comments + the merger design doc
7. 3f23ef42 drop the scoping-decisions file (it lives in this description)

Two deviations from the plan above: Q7's accuracy change landed inside commit 2 rather than getting a commit that only moved a line; and Q8 moved earlier than Q12 had it, ahead of the id removal — otherwise an intermediate commit would emit plans its own backend rejects.

Behaviour changes worth a close look

• Issue asap engine: ExactAgg(Sum) dispatch collapses sum/sum_over_time/increase/rate to same code path (function semantics lost) #301's fix now depends on --prometheus-server. sum_over_time over counter deltas and topk with no heap-bearing sid used to be pushed to the archive for an exact answer. They now miss on the ASAP tier and forward to Prometheus — a real answer where the archive gave an empty one, but "unsupported query" instead of an empty result when no fallback is configured.
• gorilla-merger/'s read path is gone. Its write path still exists and still ships blocks to S3; nothing in the backend can query them.
• NoEngineRegistered stays a fail-loud 503. No engine for a metric's tier is a deploy misconfig, not a capability miss, so it isn't quietly forwarded.

Verification

• cargo test --workspace --lib: 1153 data_plane + 422 control_plane + 108 asap_types, all passing.
• cargo test -p data_plane --tests: full e2e suite green, including e2e_controller_plans_and_backend_serves (13 tests) covering the control-plane→backend plan wire this series changes.
• cargo fmt + cargo clippy clean — every commit went through the repo's pre-commit hooks.
• Note: backend_process_e2e's single test is #[ignore]d on main for an unrelated ASAPCollector schema dependency, so it contributed no coverage here.

🤖 Generated with Claude Code