[BUG][MINOR]: Migration silent exception handling may mask schema failures #2522
Description
Context
PR #2507 migration (b1b2b3b4b5b6_fix_constraints.py) swallows all exceptions when dropping/creating constraints and indexes.
Problem
If a drop/create fails for a real reason, the migration will still "succeed" and can leave the old constraint in place, causing the bug to persist silently.
Affected lines: 75, 93, 115, 132
Failure scenarios that would be masked:
- Constraint name mismatch
- Unsupported partial index syntax
- Data violations preventing constraint creation
- Database permission issues
Current Behavior
try:
batch_op.create_unique_constraint(...)
except Exception as e:
print(f"Could not create constraint... (may already exist): {e}")
# Migration continues - schema may be unfixedSuggested Fix
Re-raise unexpected exceptions after logging, or distinguish between "already exists" errors and real failures:
try:
batch_op.create_unique_constraint(...)
except Exception as e:
# Only swallow "already exists" type errors
if "already exists" in str(e).lower() or "duplicate" in str(e).lower():
print(f"Constraint already exists, skipping: {e}")
else:
print(f"Failed to create constraint: {e}")
raise # Let deployment fail visiblyOpen Question
Local uniqueness (partial index with gateway_id IS NULL) still permits duplicates when team_id or owner_email are NULL. Is this acceptable? If not, additional constraints may be needed.