You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Four issues from review, all real, all verified rather than taken on trust.
fetchJobs requested per_page=100 but never asked for page 2, so any run with
more than 100 jobs reported partial timings. Wide matrix runs are exactly the
ones whose numbers matter, so this silently understated the busiest runs. It
now pages until total_count is reached.
Negative counts panicked instead of erroring: --runs, --history, --weeks and
--prs all reach slice bounds, and `--runs=-1` died with "slice bounds out of
range [:-1]". Reproduced before fixing. They are now rejected with a message
naming the flag.
--durations and --merge-times read no cache data but still fetched it, so they
failed whenever cache access failed, for reports that never used the result.
The cache calls are now made only for the modes that read them.
diagnose divided job medians drawn from the --runs sample by a wall-clock
median drawn from the full --history window. Mixing two windows can misstate
each cause's share and reorder them. Diagnosis now runs on the sampled window;
the full history still feeds the trend charts, where it belongs.
Tests cover pagination across two pages, the single-page stop, and rejection of
every negative count flag. 40 tests pass.
Verified live afterwards: --runs=-1 now prints a clean error, --durations
completes without touching the cache, and --why reports over the window it
actually sampled.
Co-authored-by: Balaji Ganesan <bganesan@nvidia.com>
0 commit comments