Le quatrième appel de la semaine
Catherine appelle de Maisons-Laffitte un mardi de début mai, en milieu d'après-midi. "Ça bug, mais c'est vite corrigé." C'est sa formule, je la connais, et d'habitude elle dit vrai. Elle décrit la chose en trois phrases : l'export newsletter du segment inscrits revient avec quatre-vingt-douze noms, le planning affiche quatre-vingt-douze cours actifs, mais la page compteur en affiche quatre-vingt-neuf. Trois inscrits absents. Elle a vérifié dans la base directement, ils sont bien là. "Pourquoi trois étapes pour ça ?" Elle ne pose pas la question pour moi, elle la pose pour elle. Sauf que cette fois, je m'aperçois en raccrochant que c'est la quatrième fois de la semaine que je raccroche en pensant la même chose. Quatre incidents Supabase, quatre fixes, quatre tickets refermés. Et pas une seule exception levée par la base.
Je rouvre les trois précédents en parallèle et je pose les quatre côte à côte sur l'écran. Ce n'est pas quatre bugs. C'est un seul mode d'échec, décliné quatre fois.
Les trois premiers
L'épisode 1 portait sur les GRANT par défaut que Supabase pose sur les fonctions et les policies. Une fonction SQL créée sans REVOKE explicite hérite d'un accès anon que personne n'a écrit dans la migration, et que personne n'a vu en review parce que le diff ne le montre pas. La fonction marche. Elle est juste exécutable depuis l'extérieur. [CANONICAL URL EPISODE 1: à renseigner après publication de #48 — "3 incidents Supabase, une seule racine : SECURITY DEFINER hérite de EXECUTE TO PUBLIC"]
