Dix-huit migrations, zéro CHECK. crawl_run.status, job_triggers.job_type et
band_locations.geocode_status étaient du texte libre dont les valeurs admises ne
vivaient que dans des commentaires. C'est le dénominateur commun de plusieurs
bugs de ce dépôt : un statut 'error' que plus personne n'écrivait mais qu'un
bouton d'admin ciblait encore, des lignes 'processing' qu'aucune requête ne
reprenait, un job_type réclamé par le mauvais daemon. Une faute de frappe
écrivait une ligne durablement invisible, sans jamais rien faire échouer.
Vérifié contre PostgreSQL : 'runnning' et le job_type 'geocode' sont désormais
rejetés, les valeurs légitimes passent. Les contraintes restent NOT VALID de
façon assumée — cette migration tourne au démarrage de chaque conteneur API, et
une seule ligne héritée hors domaine empêcherait l'API de démarrer. Le but est
d'arrêter la dérive, pas de réécrire le passé.
Retire geocode_queue, vestige du pipeline Nominatim que plus aucune ligne de
code ne référence.
Ajoute enfin une purge de rétention sur crawl_log, admin_audit_log et
admin_login_attempts, qui grossissaient sans fin — alors que la migration 015
avait explicitement conçu service_health pour éviter « une table qui grossit ».
Elle est appelée par migrate.js au démarrage, seul point d'accroche périodique
disponible, et volontairement tolérante : ce nettoyage ne doit jamais empêcher
l'API de démarrer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1081ea4965