Tracking: trim slow, duplicate, and dead tests

Why

cargo test --workspace (debug, as in CI) spends ~800 s running tests:
integration 328 s, devtools 259 s, planner 104 s, everything else < 70 s.
Most of that is a handful of planning-heavy tests. The suite also carries
duplicate tests, tests that assert nothing beyond "didn't panic", and ignored
tests nothing runs.

Measured 2026-10-29 on 5e89594e, one binary at a time, per-test
--report-time. Times marked † include waiting on a test-file mutex.

How to use this list

Each item gets one action:

• nightly: mark #[ignore = "nightly"] and add an --include-ignored
  step to the scheduled workflow (corpus-snapshots.yml already runs
  nightly in release). Needs the nightly job extended first (item N0).
• speed up: keep in PR CI, make it cheaper.
• dedupe: delete or merge into the named stronger test.
• delete: dead or vacuous.
• strengthen: keep, but assert the behavior its name claims.

Line numbers are from 5e89594e. Static findings were found by reading the
code and should be confirmed when they are fixed.

1. Nightly candidates (biggest PR-CI win)

• N0 Extend the nightly workflow to run
  cargo test --release --workspace -- --ignored (or a filtered subset), so
  the moves below keep coverage.
• N1 integration-tests/tests/sharing_issue_regressions.rs: every
  cost() call holds a global mutex (:36), and each search has a 30 s
  solver limit. 2–3 searches per test, run one after another.
  • sql_sum_shares_nested_windows_and_slower_readers 262 s† (3 searches)
  • slower_repeat_reuses_faster_sum 232 s†
  • exact_coarse_sum_reuses_fine_sum 166 s†
  • nested_exact_sum_reuses_newest_panes 92 s†
  • grouped_filtered_quantile_plans 59 s†
  • Option instead of nightly: lower milp_time_limit_ms. These assert
    cost relationships, not that the solver reaches the optimum.
• N2 integration-tests/tests/memo_covers_whole_workload_pass2.rs:
  topk_reuse 171 s, shared_pane_chains 125 s (the comment says each
  evaluation takes tens of seconds).
• N3 devtools/tests/planner_fuzz.rs:
  campaign_writes_summary_coverage_and_drafts 240 s, for 2 cases with a
  600 s budget. It tests the report output, so a tiny budget or a cheaper
  seed might keep it in PR CI (see S-items).
• N4 devtools/tests/stage_pipeline.rs:
  workload_examples_preserve_data_and_valid_materialized_views 168 s
  (full search over 10 workloads). See also D6.
• N5 planner/tests/runtime_install.rs forced-heap TopK tests:
  a_forced_heap_grouped_topk_sum_plan… 79 s,
  a_forced_heap_topk_count_plan… 61 s,
  a_forced_heap_counter_topk_plan… 34 s.
• N6 integration-tests/tests/planner_layering_example4.rs: the
  two stage2_physical_asap_optimization_* tests, 55 s each.
• N7 The two monthly tests in planner_layering_example4.rs
  (:138, :211) are ignored as "slow: run in release by hand", so nothing
  runs them. Move them to nightly or delete them.

2. Speed up (keep in PR CI)

• S1 plan-selection/src/search/refinement/search.rs:1218, :1398:
  they sleep 1.1 s and 2.1 s against 1 s and 2 s wall_time budgets. The
  budgets scale with wall_time, so use 20 ms budgets and 30 ms sleeps.
• S2 planner_layering_example1..4: each test rebuilds the same
  pipeline. Example 1 calls pipeline() ~25×, Example 2 ~30× (including
  repeated pipeline_with_distinct_bound(None) and (Some(3_000))),
  Example 3 runs run_a() 12× and run_b() 11×, and Example 4 plans each
  workload 2–3×. Run holds Rc, so either switch it to Arc and share
  it in a LazyLock, or fold the read-only checks into one test per
  workload.
• S3 The stage0_* tests (example1.rs:239, :251,
  example3.rs:198) build the whole pipeline only to read the frontend
  output. Call lower_promql directly.
• S4 stage_pipeline.rs: the ratio-of-quantiles workload is planned
  6+ times across stage_pipeline, memo_pricing and memo_enumeration.
  Drop the second --no-memo subprocess in
  memo_section_lists_each_step…, or check that on --promql 'sum(m)'.
• S5 executor/tests/aggregate_memory_limit.rs:157 builds 4M + 1M
  rows, and grouped_limit_memory_limit.rs:36 builds 1M rows, both under a
  16 MiB limit. Scale the limit and row counts down 4–8× together.
• S6 planner/tests/runtime_install.rs:495, 520, 852, 1570: four
  tests plan the same quantile_over_time(0.99, latency_ms[60m]). Plan it
  once in a shared OnceCell.
• S7 Remove check_compiles().unwrap() right after
  plan_installable, which already compiles the plan (installable.rs:350):
  sql_per_group_topk.rs:308, :348,
  runtime_install.rs:2434, 2486, 2868, 3099. Keep :2503 (unwrap_err).
• S8 frontend-promql/tests/support.rs:226 logical_plan builds
  every candidate, then keeps the first one with ASAP. It is used by the
  corpus loops (~1,100 queries).
• S9 promql_corpus.rs:102 and :116 lower the same corpus twice.
  Merge into one pass that counts both lowering and binding.
• S10 metrics_observability.rs:87 runs 9 corpora in one serial
  test (14 s). Split it into one test per corpus.
• S11 deployment.rs:387 compares estimates 500 times after
  asserting that the cells are equal. 1–2 probes are enough.
• S12 Merge extra test binaries into each crate's tests/main.rs
  (the link and disk cost test: link each crate's integration tests as one binary #1055 removed elsewhere):
  • frontend-sql: synthetic_packet_trace, tpch_deequ, netflow,
    bgp_analytics, bgp_jan2024_workload
  • frontend-promql: awesome_prometheus_alerts, promql_corpus,
    o11y_bench_promql, metrics_observability
  • executor: the 5 *_memory_limit binaries, merged into one
    memory_limit binary with one shared counting allocator (each needs
    its own #[global_allocator], so they can't join main.rs)

3. Dedupe

• D1 stage_pipeline.rs:848 cost_model_flag… (93 s): its &[]
  iteration produces the same default Example 3b document as
  deployment_capabilities_flag… (:913, 93 s). Drop that iteration.
• D2 stage_pipeline.rs:248 and :1584: both exhaustively plan
  Example 3a (2,187 candidates). Merge into one run with
  --max-displayed 6.
• D3 stage_pipeline.rs:739 a_target_without_a_metric… is covered
  by :98 (workload echo vs committed fixture). Delete it.
• D4 production_rollup_workloads.rs vs sketch_rollup_planning.rs:
  the same helpers and the same three query sets.
  production_sql_distinct_region_service_rollup overlaps
  rollup_controlled::production_distinct_rollup_finds_shared_kmv (35 s).
  Keep one production search per sketch family and share the helpers.
• D5 reuse_rules.rs:405: its second line repeats the call at
  :280.
• D6 planner_layering_example1.rs:912 recompiles the fixture's
  exact plan. :93 already compiles the production plan.
• D7 sql_per_group_topk.rs:306 is a subset of :316.
• D8 executor/src/values/batch.rs:844 is a subset of
  thread_safety.rs:16.
• D9 PromQL frontend duplicates. Keep the stronger test in each:
  • promql_lowering.rs:694 duplicates :674
    (promql_conformance.rs:664 is weaker still)
  • count_is_row_count has three copies: promql_conformance.rs:290,
    promql_binding_regressions.rs:34, promql_lowering.rs:504
  • irate vs rate is checked three times; keep
    promql_binding_regressions.rs:24
  • promql_conformance.rs:217 duplicates promql_lowering.rs:1408,
    :1421, :1443
  • promql_conformance.rs:318 duplicates promql_lowering.rs:894
  • promql_conformance.rs:355 and promql_equivalence::group_is_not_sum
    are covered by :1816 and :1830
  • promql_equivalence::changes_and_resets_are_not_count_over_time is
    covered by promql_conformance.rs:1158
• D10 Shape tests in corpus files that repeat conformance and SQL
  lowering tests: awesome_prometheus_alerts.rs:157, 257, 268, 280, 287
  and synthetic_packet_trace.rs:181, 190, 201.
• D11 sql_lowering.rs:447 is covered by :1381.
• D12 logical-asap-optimization/tests/per_computation_candidates.rs:77, 100, 353 are covered by src/pass1/realization.rs:556.
  src/pass1/per_computation_candidates.rs:3930 and :3953 overlap.
• D13 frontend-metricsql/tests/lowering.rs:116 is covered by
  :123.
• D14 sql-function-catalog/src/lib.rs: the three lowercase tests
  and three no-shadow tests could be one table-invariants test.
• D15 The intent-collection helpers are copied in
  promql_conformance.rs, promql_lowering.rs,
  awesome_prometheus_alerts.rs and netflow.rs. Move them to
  support.rs.

4. Delete (dead or vacuous)

• X1 integration-tests/tests/operator_sharing.rs: both tests are
  ignored. Track the work in an issue and delete the file.
• X2 Review the other 31 ignored tests: keep those tied to an active
  issue, and delete the rest.
  • planner_layering_example*: ~14, waiting on feat(pass2): shared year-aligned window segments (Q60) #628, Pass 2: the planner chooses the segment grid #634, Pass 2: sliding-window and Exponential Histogram composition — after #511 #522
  • summary_sharing.rs:402, 466, 528: waiting on Pass 2 sharing and Stage 1 coverage parity with the retired MajorPass #580
  • count_planning.rs:26: waiting on Hydra follow-ups: group totals in the executor, Pass 1 HydraCms candidates, Hydra top-k #703
  • univmon.rs:413, physical_planner/mod.rs:1750: "run by hand"
• X3 planner_layering_example1.rs:886: a should_panic test of a
  test helper.
• X4 workload_encodes_example1/2/3: they compare builders to their
  own constants. Reduce each to validate().
• X5 Assertions that can't fail:
  • sql_lowering.rs:465: let _: &Vec<usize> = cols;
  • promql_lowering.rs:1492: a binary op has children
  • frontend-metricsql/tests/lowering.rs:96:
    !to_string().is_empty()
  • planner_layering_example1.rs:373: whole > 0
• X6 metricsql-common-parser-support/src/lib.rs:
  hash_aliases_preserve_map_and_set_behavior tests std through a type
  alias, and formatter_signature_is_the_upstream_signature is dead code.
• X7 joint_search_equivalence.rs:556: the LCG "seeds" pick pairs
  from 4 fixed queries. List the pairs explicitly, or delete the test.
• X8 Tests that only check defaults or serde round trips, unless
  these are deliberate contracts: sketch.rs:857, resources.rs:59.

5. Strengthen (name promises more than the asserts check)

• A1 summary_coverage.rs:672 only checks merge().unwrap().
  Assert the remaining predicate.
• A2 joint_search_equivalence.rs:316, :333: assert that the inner
  sum is kept and that the outputs stay distinct.
• A3 stage_pipeline.rs:1584: assert the display order its name
  describes.
• A4 stage_pipeline.rs:1424: compare against the committed plan,
  or stop loading it (_committed is unused).
• A5 sql_per_group_topk.rs:346: assert something about the
  selected plan (heap or sketch).
• A6 sql_lowering.rs:2801: assert the Cardinality columns instead
  of is_ok.
• A7 frontend-metricsql/tests/lowering.rs:150: the name says
  arity, but the test only checks the top node. Assert the intent and φ.
• A8 promql_binding_regressions.rs:7 and promql_lowering.rs:982:
  replace is_ok with a check of the carried φ.
• A9 Table-drive the Gt/Lt/Ge/Le tests in binary_op.rs:144–193
  and the *_over_time tests in time_range.rs:98–153. Fix the
  time_range.rs:123 comment, which says population=false while the test
  asserts true.

Suggested order

1. N0 + N1 + N2 + N3: move or shrink the solver-bound tests. This should
   cut most of the ~10 min.
2. S1, S5, S7, D1–D3: one-line or small changes.
3. S2: the planner-layering shared fixture.
4. D9–D15 and X-items: batch deletion PRs, grouped by crate.
5. A-items: as each file is touched.