fix(gate): re-record the SQL column-literal baseline — main's MERGE GATE is red - #2884
Conversation
…ATE is red
`pnpm test:gate` fails on main:
[check-sql-column-literals] SQL column-literal population changed:
packages/core/src/team-analytics.ts: 3 site(s) now, baseline still allows 6
— re-record it (--update-baseline)
The count went DOWN: three raw column literals inside query strings were
resolved away, which is the direction this gate exists to encourage. The
baseline was not re-recorded in the same commit, which the check's own message
asks for.
This is in the MERGE GATE, so unlike the census ratchet it blocks every PR in
the queue, not just a non-blocking suite. Measured: `check-sql-column-literals`
exits 1 on a drop.
Re-recorded via `--update-baseline`: 28 sites in 14 files, the single entry
6 -> 3. Gate 732 green afterwards.
FOLLOW-UP WORTH CONSIDERING, not done here: this is the fourth time today a
DERIVED baseline going DOWN has reddened something. #2856 fixed that shape for
the census guard, where a tightening now reports healthy instead of failing.
This gate has the same shape with higher stakes — a conversion PR that improves
the tree stops the whole queue until someone notices. The census CLI already
models the better behaviour: auto-tighten, exit 0, print "COMMIT IT". Left as a
separate change because altering merge-gate semantics deserves its own review
rather than riding a red-clearing commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 32 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 SummaryRe-records the SQL column-literal baseline to match the reduced current population.
Confidence Score: 5/5The PR appears safe to merge because the updated baseline matches the current source-tree count. The sole change tightens the expected count from 6 to 3, and the checker currently detects exactly three matching sites in team analytics.
|
| Filename | Overview |
|---|---|
| scripts/lib/sql-column-literals-baseline.json | Correctly updates the team analytics baseline from 6 to 3, matching the three currently detected SQL column-literal sites. |
Reviews (1): Last reviewed commit: "fix(gate): re-record the SQL column-lite..." | 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>
Main's merge gate is red
The count went down: three raw column literals inside query strings were resolved away, which is exactly the direction this gate exists to encourage. The baseline was not re-recorded in the same commit, which the check's own message asks for.
This one is in the merge gate. Unlike the census ratchet — which auto-tightens and exits 0 —
check-sql-column-literalsexits 1 on a drop (measured), so it blocks every PR in the queue rather than reddening a non-blocking suite.The fix
--update-baseline: 28 sites in 14 files, one entry changed.Verified: the check exits 0 afterwards, and
pnpm test:gateis 732 green.Follow-up worth considering — deliberately not done here
This is the fourth time today a derived baseline going down has reddened something:
#2856 fixed the shape for the census: a tightening now reports healthy instead of failing, so "somebody improved the tree and hasn't re-recorded yet" stops being an emergency. This gate has the same shape with higher stakes — a conversion PR that improves the tree stops the whole queue until a human notices and re-records.
The census CLI already models the better behaviour: auto-tighten, exit 0, print "COMMIT IT". Porting that here is a small change, but it alters merge-gate semantics, so it deserves its own review rather than riding along in a red-clearing commit. Flagging rather than doing.
🤖 Generated with Claude Code