ezer-mishpati/legal-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(halacha): UNIQUE(case_law_id, halacha_index) backstop (#83) #51

Merged
chaim merged 1 commits from feat/halacha-unique-index into main 2026-06-03 13:07:31 +00:00
Conversation 0 Commits 1 Files Changed 2 +380 -3
chaim commented 2026-06-03 13:07:25 +00:00
Owner
Copy Link

#83 — חוסן pipeline: ערובת מספור תקין

  • מוסיף CREATE UNIQUE INDEX idx_halachot_unique_index ON halachot(case_law_id, halacha_index).
  • ה-index מוקצה כ-MAX+1 תחת store-lock תוך-תהליכי + advisory lock חוצה-תהליכים, אז התנגשות לא אמורה לקרות — אבל לפי המחקר (FireHydrant/OneUptime) האילוץ הוא ערובת התקינות, הנעילה היא אופטימיזציה. ריצה כפולה/מרוץ כעת נכשלת בקול (UniqueViolation, ה-chunk נשאר לא-מסומן → resume נקי) במקום לצרף כפילויות בשקט (שורש ה-over-extraction של 2026-05/06).

הכנת נתונים (לפני האילוץ, מגובה ב-data/audit/halacha-reindex-backup-*.sql)

6 הפסקים שעדיין נשאו אינדקסים מתנגשים (9 קבוצות — עקרונות מובחנים שחלקו מספר, לא כפילויות תוכן) מוספרו מחדש לאינדקסים ייחודיים רצופים. נותרו 0 קבוצות כפולות.

אומת

  • advisory lock מחזיק חוצה-תהליכים; נתיב ה-DB ישיר (asyncpg, ללא transaction-pooler) → נעילת session בטוחה (83.1).
  • force=True מבצע delete+checkpoint-clear בטרנזקציה אחת (83.5).
  • האילוץ דוחה הכנסת אינדקס כפול (UniqueViolation — נבדק).
  • כל המערך 156 passed.

גם

מתעד ב-TaskMaster את כל יוזמת איכות-ההלכות (#81-#84 + תתי-משימות מבוססות-מחקר + סטטוסים).

הערה

83.3 (content_hash) מיותר — #82 (dedup-on-insert) כבר מבטיח אידמפוטנטיות. נותר ל-follow-up: 83.4 (retry-on-violation, אם יידרש), והשאר ב-#84.

🤖 Generated with Claude Code

## #83 — חוסן pipeline: ערובת מספור תקין - מוסיף `CREATE UNIQUE INDEX idx_halachot_unique_index ON halachot(case_law_id, halacha_index)`. - ה-index מוקצה כ-MAX+1 תחת store-lock תוך-תהליכי + advisory lock חוצה-תהליכים, אז התנגשות לא אמורה לקרות — אבל לפי המחקר (FireHydrant/OneUptime) **האילוץ הוא ערובת התקינות**, הנעילה היא אופטימיזציה. ריצה כפולה/מרוץ כעת **נכשלת בקול** (UniqueViolation, ה-chunk נשאר לא-מסומן → resume נקי) במקום לצרף כפילויות בשקט (שורש ה-over-extraction של 2026-05/06). ## הכנת נתונים (לפני האילוץ, מגובה ב-`data/audit/halacha-reindex-backup-*.sql`) 6 הפסקים שעדיין נשאו אינדקסים מתנגשים (9 קבוצות — עקרונות מובחנים שחלקו מספר, **לא** כפילויות תוכן) מוספרו מחדש לאינדקסים ייחודיים רצופים. נותרו 0 קבוצות כפולות. ## אומת - advisory lock מחזיק חוצה-תהליכים; נתיב ה-DB ישיר (asyncpg, **ללא** transaction-pooler) → נעילת session בטוחה (83.1). - `force=True` מבצע delete+checkpoint-clear בטרנזקציה אחת (83.5). - האילוץ דוחה הכנסת אינדקס כפול (UniqueViolation — נבדק). - כל המערך **156 passed**. ## גם מתעד ב-TaskMaster את כל יוזמת איכות-ההלכות (#81-#84 + תתי-משימות מבוססות-מחקר + סטטוסים). ## הערה 83.3 (content_hash) מיותר — #82 (dedup-on-insert) כבר מבטיח אידמפוטנטיות. נותר ל-follow-up: 83.4 (retry-on-violation, אם יידרש), והשאר ב-#84. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
chaim added 1 commit 2026-06-03 13:07:25 +00:00
feat(halacha): UNIQUE(case_law_id, halacha_index) backstop + task tracking (#83) 0f64b4c062 
#83 pipeline robustness — the index-numbering correctness guarantee:
- Add CREATE UNIQUE INDEX idx_halachot_unique_index ON halachot(case_law_id,
  halacha_index). The extractor assigns the index as MAX+1 under an in-process
  store-lock + a cross-process pg advisory lock, so collisions shouldn't occur
  in normal operation — but per the research (FireHydrant/OneUptime) the
  constraint is the actual correctness guarantee while the lock is the
  optimization. A racing/double run now fails LOUDLY (UniqueViolation, chunk
  left un-checkpointed → clean resume) instead of silently appending the
  duplicates that were the 2026-05/06 over-extraction root cause.

Data prep (run against the live DB before the constraint, backed up to
data/audit/halacha-reindex-backup-*.sql): the 6 precedents that still carried
colliding halacha_index values (9 groups, distinct principles that shared a
number — NOT content dups) were renumbered to unique sequential indices.

Verified: advisory lock holds cross-process and the DB path is direct asyncpg
(no transaction-pooler), so the session lock is safe (83.1); force=True does
delete+checkpoint-clear in one transaction (83.5); constraint rejects a
duplicate-index insert (integration-checked). Full suite 156 passed.

Also commits the TaskMaster tracking for the whole halacha-quality initiative
(#81-#84 + research-backed subtasks, statuses).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
chaim merged commit 7ebddcce6d into main 2026-06-03 13:07:31 +00:00
chaim deleted branch feat/halacha-unique-index 2026-06-03 13:07:31 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
chaim
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ezer-mishpati/legal-ai#51
Delete Branch "feat/halacha-unique-index"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?