Skip to content

fix(db): renumber colliding migration 0181 to 0182 - #9090

Merged
JSONbored merged 1 commit into
mainfrom
fix/migration-0181-collision
Jul 26, 2026
Merged

fix(db): renumber colliding migration 0181 to 0182#9090
JSONbored merged 1 commit into
mainfrom
fix/migration-0181-collision

Conversation

@JSONbored

Copy link
Copy Markdown
Owner

Problem

db:migrations:check is currently failing on main:

check-migrations: duplicate migration number 0181: "0181_alert_dedup_claims.sql", "0181_decision_replay_inputs.sql".
Two PRs grabbed the same number — renumber the newest to the next free number (0182).

Two PRs merged 18 minutes apart and both picked migration number 0181:

This blocks CI for every subsequent PR against main.

Fix

Renumber the later-merged file to the next free number, 0182. Verified no code or test references either migration by filename or number (only test/unit/alerts.test.ts references 0181_alert_dedup_claims.sql, which keeps its number).

check-migrations: 186 migrations OK — contiguous 0001..0182 (5 grandfathered duplicates: 0015, 0017, 0074, 0090, 0156), no new duplicates. Next free: 0183

Two PRs merged within 18 minutes of each other and both grabbed migration
number 0181 (0181_alert_dedup_claims.sql from #8985, 0181_decision_replay_inputs.sql
from #9014), breaking db:migrations:check on main for every subsequent PR.

Renumbers the later-merged file (decision_replay_inputs) to 0182, the next free
number. No code or test references either file by name/number, so this is a
pure rename.
@JSONbored JSONbored self-assigned this Jul 26, 2026
@JSONbored
JSONbored merged commit de430a0 into main Jul 26, 2026
2 checks passed
@JSONbored
JSONbored deleted the fix/migration-0181-collision branch July 26, 2026 16:50
@superagent-security

Copy link
Copy Markdown
Contributor

Superagent didn't find any vulnerabilities or security issues in this PR.

@codecov

codecov Bot commented Jul 26, 2026

Copy link
Copy Markdown

❌ 1 Tests Failed:

Tests completed Failed Passed Skipped
22047 1 22046 21
View the top 1 failed test(s) by shortest run time
test/unit/reputation-wiring.test.ts > shouldSkipAiForReputation (helper) > submission-cadence signal (#4514) > FLAG-ON: true for a machine-paced submitter even though every submission itself looks fine (quality-neutral)
Stack Traces | 0.169s run time
AssertionError: expected false to be true // Object.is equality

- Expected
+ Received

- true
+ false

 ❯ test/unit/reputation-wiring.test.ts:299:105

To view more test analytics, go to the Test Analytics Dashboard
📋 Got 3 mins? Take this short survey to help us improve Test Analytics.

JSONbored added a commit that referenced this pull request Jul 26, 2026
…stale migration-number comment

loopover_ai_review_verdict_flip_escalated_total was emitted (processors.ts) with
no DEFAULT_METRIC_META entry, failing the completeness drift guard.

Also corrects verdict-flip-store.ts's header comment, which still said
"migration 0182" -- the ai_review_verdict_flips migration was bumped to 0183
after this branch rebased past #9090's 0181->0182 renumbering, but the comment
was never updated.
JSONbored added a commit that referenced this pull request Jul 26, 2026
…ickiness + flip-count escalation (#9094)

* fix(review): stop AI-review verdict-shopping — content-fingerprint stickiness + flip-count escalation

The AI reviewer is non-deterministic, and the review cache keys purely
on head SHA, so a contributor could force fresh re-rolls (a no-op
recommit invalidating the cache key, or a same-head retry once the
30-minute non-cacheable cooldown lapses) until a lucky clean roll
auto-merged a PR another roll had flagged as blocked. Two independent
defenses:

1. getCachedAiReviewAcrossHeads (src/db/repositories.ts): a fallback
   used only when the exact-head lookup misses. The input fingerprint
   already hashes the actual per-file patch content, not just the head
   SHA, so an identical fingerprint under a different head means the
   reviewed content is genuinely unchanged -- reuse the prior verdict
   instead of spending an independently-random fresh roll on it.

2. A per-PR verdict-flip counter (migration 0183, src/review/
   verdict-flip-guard.ts + verdict-flip-store.ts): every FRESH
   (non-cache-hit) verdict in block mode is compared against the PR's
   last fresh verdict; a flip is a change in whether the verdict had a
   blocking AI defect. Once flips clear a threshold, the gate holds for
   a human instead of trusting the newest roll, regardless of what it
   says.

Fixed a pre-existing test (#ops-review-burst) whose fixture returned
identical patch content across two different head SHAs -- exactly the
no-op-recommit case fix #1 is designed to reuse, which made its own
aiCalls assertion test the wrong thing; it now varies real content
between heads and stays a valid regression for the ORIGINAL concern
(a genuinely new commit is never suppressed).

* fix(selfhost): register the verdict-flip-escalation metric and fix a stale migration-number comment

loopover_ai_review_verdict_flip_escalated_total was emitted (processors.ts) with
no DEFAULT_METRIC_META entry, failing the completeness drift guard.

Also corrects verdict-flip-store.ts's header comment, which still said
"migration 0182" -- the ai_review_verdict_flips migration was bumped to 0183
after this branch rebased past #9090's 0181->0182 renumbering, but the comment
was never updated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant