Files
zlareb1andClaude Opus 4.7 9b6eb38dc9 Bound date-range pipeline with TS_FILTER_END upper edge
Address review comment 3194583058: the date-range workflow promised
"between A and B" but only filtered ts >= '{{TS_FILTER}}', so a request
like "between 2026-04-01 and 2026-05-01" silently included every nightly
after 2026-05-01 and let cumulative deltas drift as new runs accumulated.

Add a parallel TS_FILTER_END / KEEPER_SKILL_THRESHOLD_END upper bound that
mirrors the existing lower bound at every layer:

  - All 6 staging SQL queries: append `AND ts < '{{TS_FILTER_END}}'`.
  - `rebuild.sh`: accept `$3` as the upper bound; sed-substitute both
    placeholders; export both env vars for the Python pipeline.
  - `_common.py`: parse `KEEPER_SKILL_THRESHOLD_END` (defaults to far-future
    sentinel `9999-12-31`) so unbounded callers keep today's behavior.
  - `build_pr_nightly_map.py` and `compute_deltas.py`: filter PRs against
    the half-open `[THRESHOLD, THRESHOLD_END)` interval.
  - `SKILL.md`: update Phase 2 invocation and Example 2 ("between
    2026-04-01 and 2026-05-01") to pass both bounds.
  - `tests/test_common.py`: 2 new cases for the `THRESHOLD_END` default
    and explicit-env-var parse path. 23 -> 25 cases, all pass.

Backward-compat regression contract: invoking `rebuild.sh ... 2026-03-25`
(no upper bound) still produces `cumulative_gains.tsv` md5
e5a27e01008ef7e23597ee041f68103b and the `#99651` PR-branch isolation row
bit-identical. Bounded smoke (`... 2026-03-25 2026-04-15`) verified to
produce strictly fewer rows in `bench_summary.tsv` and `merged_metrics.tsv`,
with max `run_ended` < `2026-04-15` and all `pr_to_nightly.tsv` `merged_at`
< `2026-04-15`.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
2026-05-06 10:27:53 +00:00

50 lines
1.8 KiB
SQL

-- container metrics: peak memory bytes; CPU rate (cores) p95 & max
WITH base AS (
SELECT scenario, backend, commit_sha, name, node,
toUnixTimestamp(ts) AS t,
max(value) AS v
FROM keeper_stress_tests.keeper_metrics_ts
WHERE source = 'container'
AND branch = 'master'
AND ts >= '{{TS_FILTER}}'
AND ts < '{{TS_FILTER_END}}'
AND node IN ('keeper1', 'keeper2', 'keeper3')
AND name IN ('container_cpu_usage_usec', 'container_memory_bytes')
GROUP BY scenario, backend, commit_sha, name, node, ts
),
cpu_rated AS (
SELECT scenario, backend, commit_sha, node,
(v - lagInFrame(v, 1) OVER (PARTITION BY scenario, backend, commit_sha, node ORDER BY t))
/ nullIf(t - lagInFrame(t, 1) OVER (PARTITION BY scenario, backend, commit_sha, node ORDER BY t), 0) / 1e6 AS cores
FROM base
WHERE name = 'container_cpu_usage_usec'
),
cpu_agg AS (
SELECT scenario, backend, commit_sha,
round(avg(cores), 2) AS avg_cpu_cores,
round(quantile(0.95)(cores), 2) AS p95_cpu_cores,
round(max(cores), 2) AS max_cpu_cores
FROM cpu_rated
WHERE cores IS NOT NULL AND cores >= 0
GROUP BY scenario, backend, commit_sha
),
mem_agg AS (
SELECT scenario, backend, commit_sha,
round(max(v) / 1e9, 3) AS peak_mem_gb,
round(avg(v) / 1e9, 3) AS avg_mem_gb
FROM base
WHERE name = 'container_memory_bytes'
GROUP BY scenario, backend, commit_sha
)
SELECT
coalesce(m.scenario, c.scenario) AS scenario,
coalesce(m.backend, c.backend) AS backend,
coalesce(m.commit_sha, c.commit_sha) AS commit_sha,
m.peak_mem_gb, m.avg_mem_gb,
c.avg_cpu_cores, c.p95_cpu_cores, c.max_cpu_cores
FROM mem_agg m
FULL OUTER JOIN cpu_agg c
ON m.scenario = c.scenario AND m.backend = c.backend AND m.commit_sha = c.commit_sha
ORDER BY scenario, backend, commit_sha
FORMAT TSVWithNames