Windowing issue

[Balatripura587]

Type of change

• Refactor
• New feature
• Bug fix
• Optimization
• Documentation Update

Description

Changepoint detection (EDivisive/hunter) needs enough samples before and after a point to be reliable. We were sometimes reporting changepoints in the first few points (e.g. the 2nd) without that context, so anomalies were treated as regressions and caused noise in CI (e.g. OVN).

Solution

• Buffer: The first 5 points are treated as the window edge (CHANGEPOINT_BUFFER in orion/constants.py). Any changepoint in that range is re-validated.
• Window expansion: If a changepoint is in the buffer, we expand the lookback window, then re-run detection. We keep it as a regression only if the expanded run still has a changepoint; otherwise we treat it as a false positive

Testing

Verified with all three output formats (text, JSON, junit).
Example:
orion --lookback 15d --since 2026-01-20 --hunter-analyze --config hack/ci-tests/ci-tests-early-cp.yaml --metadata-index "orion-integration-test-data*" --benchmark-index "orion-integration-test-metrics*" --es-server=${QE_ES_SERVER} --node-count true --input-vars='{"version": "4.20"}' --output-format junit > results-early-cp.x ml
Output:

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign afcollins for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vishnuchalla]

/test

[vishnuchalla]

/test ?

[vishnuchalla]

/test payload-control-plane-6nodes-nodeploy

[vishnuchalla]

Looking at the default values, if the whole point is to make sure to fetch 5 more data points within last 10 days of runs, why not simply look at expand points which tells to look at atleast 5 data points in the past?

[Balatripura587]

We need both because of how the matcher works currently:
It first filters by time window, then caps with lookback_size. EXPAND_POINTS only raises that cap; it doesn’t change the window, so with the same window we can’t get more runs. EXPAND_DAYS extends the window so more runs are in range. We set lookback_size = current_points + 5 so we request at most 5 more points—if the extended window has more than 5 extra, we still only take 5, since that’s all we need for re-validation.