Une décision sur les paiements qui était à moitié vraie
Expo Router makes any file under app/ reachable by path whether the UI links to it or not, so an 'unwired' payments screen was still deep-linkable.
Ça disait que ça marchait
Vert, 200, enregistré, « déjà géré » — et faux. Aucune erreur sur laquelle s'appuyer.
En re-vérifiant le débranchement des paiements, qui avait consigné « confirmé que les trois autres applications n'avaient jamais eu de point d'entrée en direct ». En ré-auditant correctement, le payments/[applicationId].tsx du mobile était encore un fichier routable en direct. Aucun bouton n'y menait, vrai, mais Expo Router rend tout fichier sous app/ atteignable par chemin que l'interface y renvoie ou non, donc il était encore accessible en deep link. Un doublon plus complet était déjà sous _dormant/ depuis un nettoyage antérieur, et j'avais visiblement vérifié celui-là et conclu que la fonctionnalité était dormante sans remarquer que l'original était encore dans l'arbre de routage en direct à côté.
J'ai renommé le dossier pour qu'Expo Router l'ignore, contenu intact. Je suis aussi allé une couche plus profond que la décision d'origine et j'ai ajouté une protection qui renvoie 404 sur les quatre routes de paiement quelle que soit l'authentification, ce qui ferme le webhook du fournisseur de paiement — @Public() et atteignable par le vrai fournisseur pendant tout ce temps.
« Aucun bouton n'y renvoie » et « ce n'est pas atteignable » sont des affirmations différentes dans un routeur basé sur les fichiers. Ça vaut la peine de re-vérifier un « confirmé inatteignable » antérieur contre le mécanisme de routage réel, surtout des mois plus tard quand le raisonnement d'origine n'est plus dans ma tête.