fix(gate): re-record the SQL baseline — main is red after #2864 - #2878
Conversation
test:gate and both pretest hooks fail on main right now. #2864 removed three legacy comparisons from team-analytics.ts, its baseline entry still allowed six, and this gate fails on a LOWERED count by design so a migrated slot cannot be silently regrown into. 30 -> 28. MY SEQUENCING ERROR, not a flaw in either change. The four analytics conversions were branched and reviewed before the gate existed (#2841), so none of them carries a baseline update; the gate then landed first and every one of them breaks main as it merges. The three still open (#2866, #2870, #2871) will each do this again unless their baselines are re-recorded, which I am doing next. Worth stating because the downward direction looks like pedantry until it fires: it exists so a migrated site cannot leave an unused allowance behind. The cost is that a conversion and the gate must land in a known order, and I did not think about that ordering when I opened them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 3 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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 (1)
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 |
Greptile SummaryThe PR synchronizes the SQL-column-literal baseline with the three remaining legacy comparisons in team analytics.
Confidence Score: 5/5The PR appears safe to merge because the updated baseline exactly matches the current source count. The checker intentionally rejects stale allowances after counts decrease, and changing the team analytics entry from 6 to 3 restores agreement without weakening the gate.
|
| Filename | Overview |
|---|---|
| scripts/lib/sql-column-literals-baseline.json | Correctly updates the team analytics baseline to match the current count of three legacy SQL-column comparisons. |
Reviews (1): Last reviewed commit: "fix(gate): re-record the SQL baseline — ..." | Re-trigger Greptile
I checked the census before defending this design and got the wrong answer: I read its header comment
("fails on a RISE and equally on a DROP that was not recorded") and concluded my gate matched
convention. It does not. MEASURED just now — inflate a census baseline entry and run `--strict`: it
exits 0 and tightens. Mine exited 1.
The cost of that difference, twice in one day: #2878 (main red after a conversion I wrote landed
without re-recording) and #2884 (main's MERGE GATE red, fixed by hand by someone who had never
touched this gate). Neither author did anything wrong — they removed legacy literals, the direction
this check exists to encourage, and it failed them for succeeding.
The census's own rationale applies unchanged: a permanently-red gate is a bigger hole than a stale
allowance, because it gets ignored and then nothing is guarded at all. So the ceiling follows the
count down and says so, while the RISE check — the actual purpose — still fails hard.
MEASURED, both directions: a drop prints "baseline tightened ... COMMIT IT" and exits 0; a rise still
exits 1; a clean tree exits 0.
Residual named in the source rather than glossed: in CI the tightening write is discarded with the
runner, so the committed baseline stays stale until someone commits a tightened one. Bounded — only
up to the old count, only in a file that already had literals.
This also removes the coupling that made me add baseline re-records to three conversion PRs; those
commits are harmless now but were only ever working around this.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pnpm test:gateand bothpretesthooks fail onmainright now. Merge this first.What happened
#2841 (the SQL gate) merged, then #2864 merged. #2864 removed three legacy comparisons from
team-analytics.ts, but its baseline entry still allows six — and this gate fails on a lowered count by design, so a migrated slot cannot be silently regrown into later.Baseline 30 → 28.
This is my sequencing error
The four analytics conversions were branched and reviewed before the gate existed, so none of them carries a baseline update. The gate then landed first, which means each of them breaks
mainas it merges. I opened all five without thinking about the order they would land in.The three still open — #2866, #2870, #2871 — will each do this again. I am adding baseline updates to them next so they land clean.
Note on the downward check
The "count went down" failure looks like pedantry until it fires. It exists so a migrated site cannot leave an unused allowance behind for the surface to regrow into — the same rot as an allow-list entry for a deleted function. The real cost is that a conversion and its gate have to land in a known order, which is a coupling I created and did not plan for.
Verification
pnpm test:gategreen with the re-recorded baseline · lint 0 ·node scripts/check-sql-column-literals.mjsexit 0.🤖 Generated with Claude Code