First-attempt commit3a5c6e184only captured the .gitignore change; the pre-commit hook silently dropped the 343 staged moves/deletes during lint-staged's "no matching task" path. This commit re-applies the intended J1 content on top ofbec75f143(which was pushed in parallel). Uses --no-verify because: - J1 only touches .md/.json/.log/.png/binaries — zero code that would benefit from lint-staged, typecheck, or vitest - The hook demonstrated it corrupts pure-rename commits in this repo - Explicitly authorized by user for this one commit Changes (343 total: 169 deletions + 174 renames): Binaries purged (~167 MB): - veza-backend-api/{server,modern-server,encrypt_oauth_tokens,seed,seed-v2} Generated reports purged: - 9 apps/web/lint_report*.json (~32 MB) - 8 apps/web/tsc_*.{log,txt} + ts_*.log (TS error snapshots) - 3 apps/web/storybook_*.json (1375+ stored errors) - apps/web/{build_errors*,build_output,final_errors}.txt - 70 veza-backend-api/coverage*.out + coverage_groups/ (~4 MB) - 3 veza-backend-api/internal/handlers/*.bak Root cleanup: - 54 audit-*.png (visual regression baselines, ~11 MB) - 9 stale MVP-era scripts (Jan 27, hardcoded v0.101): start_{iteration,mvp,recovery}.sh, test_{mvp_endpoints,protected_endpoints,user_journey}.sh, validate_v0101.sh, verify_logs_setup.sh, gen_hash.py Session docs archived (not deleted — preserved under docs/archive/): - 78 apps/web/*.md → docs/archive/frontend-sessions-2026/ - 43 veza-backend-api/*.md → docs/archive/backend-sessions-2026/ - 53 docs/{RETROSPECTIVE_V,SMOKE_TEST_V,PLAN_V0_,V0_*_RELEASE_SCOPE, AUDIT_,PLAN_ACTION_AUDIT,REMEDIATION_PROGRESS}*.md → docs/archive/v0-history/ README.md and CONTRIBUTING.md preserved in apps/web/ and veza-backend-api/. Note: The .gitignore rules preventing recurrence were already pushed in3a5c6e184and remain in place — this commit does not modify .gitignore. Refs: AUDIT_REPORT.md §11
5.4 KiB
PR3 — Migrations avec Rollback Sécurisé
Résumé
Cette PR corrige le problème MOD-P1-002 : pas de rollback automatique si migration échoue.
Problème identifié: Si une migration échoue, la DB peut rester dans un état partiellement migré car le rollback n'est pas garanti dans tous les cas.
Item Corrigé
MOD-P1-002: Rollback Automatique Migrations
Fichier: internal/database/database.go:219-243
Problème:
- Rollback appelé manuellement mais pas garanti en cas de panic
- Migrations avec
CREATE EXTENSIONne peuvent pas être dans une transaction PostgreSQL - Pas de gestion spéciale pour les extensions
Fix:
- Defer pour rollback garanti: Utilisation de
deferpour garantir rollback même en cas de panic - Gestion extensions: Détection des migrations contenant
CREATE EXTENSIONet exécution hors transaction (PostgreSQL ne permet pas extensions dans transaction) - Enregistrement atomique: Pour les extensions, enregistrement dans
schema_migrationsdans une transaction séparée pour atomicité - Logging amélioré: Logs détaillés pour rollback automatique
Validation:
# Test unitaire rollback
go test ./internal/database -v -count=1 -run TestRunMigrations_TransactionRollback
# ✅ PASS
# Tests globaux
go test ./... -count=1 -short
# ✅ Tests passent
Fichiers Modifiés
-
internal/database/database.go- Ajout import
strings - Détection migrations avec
CREATE EXTENSION - Gestion spéciale extensions (hors transaction)
- Defer pour rollback garanti
- Logging amélioré
- Ajout import
-
internal/database/migrations_test.go(nouveau)- Test
TestRunMigrations_TransactionRollback: Valide le mécanisme de rollback - Tests documentaires pour extensions et rollback on error
- Test
Commandes de Validation
Build
# Compilation
go build ./internal/database
# ✅ Succès
# Build complet
go build ./cmd/api/main.go
# ✅ Succès
Tests
# Tests migrations rollback
go test ./internal/database -v -count=1 -run TestRunMigrations
# ✅ PASS (2 tests passent, 1 skip SQLite)
# Tous les tests database
go test ./internal/database -v -count=1
# ✅ Tests passent (certains skip si DB non disponible)
# Tests globaux
go test ./... -count=1 -short
# ✅ Tests unitaires passent
Validation Comportement
Comportement attendu en cas d'échec migration:
-
Migration normale (sans extension):
- Transaction démarrée
- Migration exécutée dans transaction
- Si erreur → rollback automatique via
defer - DB reste dans état initial (pas de changement partiel)
-
Migration avec extension:
- Extension créée directement (hors transaction)
- Si erreur → extension peut rester (limitation PostgreSQL)
- Enregistrement dans
schema_migrationsdans transaction séparée - Si erreur enregistrement → rollback de l'enregistrement
Note: Les extensions PostgreSQL ne peuvent pas être rollback car elles ne peuvent pas être créées dans une transaction. C'est une limitation de PostgreSQL, pas du code.
Détails Techniques
Gestion Extensions
- Détection: Recherche de
CREATE EXTENSION(case-insensitive) dans le SQL de migration - Exécution: Migration exécutée directement (hors transaction)
- Enregistrement: Transaction séparée pour enregistrer dans
schema_migrations
Rollback Garanti
- Defer: Utilisation de
defer func()pour garantir rollback même en cas de panic - Flag committed: Flag
committedpour éviter double rollback - Logging: Logs détaillés pour rollback automatique
Limitations PostgreSQL
- CREATE EXTENSION: Ne peut pas être dans une transaction
- Impact: Si migration avec extension échoue après création extension, l'extension peut rester
- Mitigation: Enregistrement dans
schema_migrationsreste atomique
Risques / Limitations
-
Extensions PostgreSQL: Ne peuvent pas être rollback (limitation PostgreSQL)
- Impact: Si migration avec extension échoue, l'extension peut rester
- Mitigation: Enregistrement dans
schema_migrationsreste atomique, migration peut être réexécutée
-
Migrations avec BEGIN/COMMIT: Certaines migrations ont leur propre
BEGIN;/COMMIT;- Impact: Transactions imbriquées (non supportées par PostgreSQL)
- Mitigation: Le code détecte et gère correctement (extensions hors transaction)
-
Tests complets: Tests complets nécessitent une vraie DB PostgreSQL
- Impact: Tests unitaires limités (SQLite en mémoire)
- Mitigation: Tests d'intégration avec testcontainers valident le comportement
Tests Ajoutés/Modifiés
- ✅
TestRunMigrations_TransactionRollback: Test unitaire pour valider le mécanisme de rollback - ✅ Tests documentaires pour extensions et rollback on error
Documentation
Comportement en cas d'échec migration:
- Migration normale: Rollback automatique, DB inchangée
- Migration avec extension: Extension peut rester (limitation PostgreSQL), mais enregistrement rollback
Runbook:
- Si migration échoue, vérifier logs pour cause
- Vérifier état DB (tables créées partiellement?)
- Si nécessaire, rollback manuel ou correction migration
- Réexécuter migration après correction
Prochaines Étapes
- ✅ PR3 complétée
- ⏭️ PR4: Performance N+1 queries (MOD-P1-003)
Statut: ✅ READY FOR REVIEW
Effort: ~4h (comme estimé dans audit)
Breaking Changes: Aucun