seed(stand): two years of activity on both stands - #2501
Conversation
The compose stand seeded 60 days and the deployed stand 365, so a developer and CI were looking at differently shaped data, and neither reached far enough back to show a year-over-year view. Both seed 730 days now. That is wider than any single request the analytics API will answer — it refuses a period of 400 days or more — which is exactly the trap INFRA.md already names. The mitigation was built with the helper: `query_window` returns the queryable tail of the seeded range. Four call sites still read `data_window` raw, against the note in the package's own docstring, and each would have started answering 400 the moment the window grew; they go through the helper now. Clamping also keeps the paged drilldown walks bounded: they page a fixed 399 days whatever the seed window becomes, rather than growing with it. A reconciliation must pass the SAME clamped period to both sides — the walk and the scalar it is checked against — or it compares two different periods. Both pairs do. Signed-off-by: Konstantin Tursunov <Konstantin.Tursunov@constructor.tech>
|
Warning Review limit reached
Next review available in: 115 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The titles the export test needs went to the dev lead's EARLIEST commits, so widening the seed window pushed them out of the period the suite can ask about — the API answers no period of 400 days or more, so a request for "the seeded range" is clamped to its tail, and the compose lane failed on a stand that did contain every title. They go to the most recent commits instead, which the tail always covers. The dealing moved after the row loop rather than into it: the message column is found by name, so the row tuple's shape stays the one thing the link parity tests read positionally. Signed-off-by: Konstantin Tursunov <Konstantin.Tursunov@constructor.tech>
|
Folded into #2498 — the four commits belong together: the full-suite lane is what makes the seed changes worth running, and the hostile-title fix only exists because the wider window exposed it. Closing this in favour of the combined PR. |
1 participant
What
The compose stand seeded 60 days and the deployed stand 365. Both seed 730 now, so a developer and CI look at the same shape of data, and the range finally reaches back far enough for a year-over-year view.
The trap this walks into on purpose
730 days is wider than any single request the analytics API will answer —
MAX_PERIOD_DAYSis 400 and the check is>=, on both/v1/metric-resultsand/v1/metric-drilldown.INFRA.mdalready names this exact failure ("730-day seed window"): a window-derived request starts answering 400 and it reads like a broad data problem rather than a period that is simply too long.The mitigation was already built —
tests/stand/api/analytics/query_windowreturns the queryable tail of the seeded range, and the package docstring says every request wanting "a real period" should go through it. Four call sites still readdata_windowraw, and each would have gone red the moment the window grew:test_drilldown.py_request_forand_period_valuetest_drilldown_rebuild.py_requestand_period_valueThey go through the helper now, so the suite asks about the most recent 399 days whatever the seed window is.
INFRA.md's row is rewritten to match: the guard is no longer "keep the seed inside the API limit", it is "no test may readdata_windowraw".A reconciliation has to pass the same clamped period to both sides — the evidence walk and the scalar it is checked against — or it compares two different periods and the disagreement looks like a data bug. Both pairs above are converted together for that reason.
What the first CI run caught
test_export_cells_match_the_page_and_hostile_values_stay_inertfailed with "no evidence title begins with=". The seed plants deliberately hostile commit titles for the export-escaping test, and it dealt them to the dev lead's earliest commits. Clamping the query to the tail of a 730-day window put them out of reach — the stand did contain every title, and the suite could not see one.They are dealt to the most recent commits now, which the tail always covers. The dealing moved to after the row loop rather than inside it, and finds the message column by name, so the row tuple's shape stays the one thing the link-parity tests read positionally. Verified offline against the real column list: all six titles land on the final day of the window at both 60 and 730 days.
Cost
The paged walk grows on the compose lane.
test_git_commit_drilldown_pages_and_reconcilespages withlimit=1and no budget, so its request count tracks the queried period — which on compose goes from 60 days of data to a clamped 399. Measured offline: 434 → 2,877 rows for that selection. At CI's latency that is a minute or two, not a lane-breaker, and it is bounded from here on: the clamp holds the walk at 399 days however wide the seed becomes. The deployed stand barely moves (365 → 399).The compose seed itself gets bigger — 60 → 730 days is roughly 12× the rows for every developer bring-up and for the
Stand E2Egate. Measured in this PR's own run: api-smoke 8m31s against a 45-minute ceiling, ui-journeys 5m39s and green.SEED_DAYSstill overrides per run.