Repository Public
Latest commit [ka2] fix connecteur gestion_isr: la table listings passée derrière RLS — lecture dynamique de LISTINGS_URL (vue listings_public) + retry anti-timeout. Depuis le run du 2026-10-20 15:03 le connecteur rapportait found=0 « ok » (alerte dérive, retraits suspendus) : le portail location.gestion-isr.com a migré ses annonces publiques vers la VUE expurgée /rest/v1/listings_public (migration 145-listings-vue-publique.sql visible dans le JS inline) et l'ancienne table /rest/v1/listings renvoie désormais 200 [] à la clé anon (RLS) — zéro silencieux classique. Fix : le connecteur lit maintenant le chemin REST dans la const LISTINGS_URL du HTML du portail (même philosophie que l'URL/clé Supabase déjà lues dynamiquement — se répare seul au prochain renommage), erreur FRANCHE si la const disparaît. Piège rencontré en route : la vue est coûteuse côté Postgres — « canceling statement due to statement timeout » (57014 → 500) sur 2 runs sur 4 → retry ×3 (pause 4 s/8 s, pattern solaris 8eff094), même URL (timeout serveur, pas un cache). Schéma de la vue identique à l'ancienne table pour tous les champs consommés (pk, id_app, titre, id, loyer, adresse_geo, units, photos…) : _parse_row inchangé, external_id stables. Fixture ré-enregistrée (2 requêtes, 20 annonces), pytest gestion_isr 2 passed. Testé : fetch() venv → 20 annonces (médiane 20 ; 21 lignes dans la vue, 1 exclue par les filtres), run.py sync gestion_isr → found=20 ok (updated=1, 2,5 s), pm2 restart lou-ka-sync, site :8095 → 200. 9be02d9