Commit f019b09b authored by Kourser's avatar Kourser
Browse files

Le contrôle du relais retrouve les noms qu'il désigne

« pnpm verif » s'arrêtait avant la moitié de la suite, sur un module
introuvable. Derrière, quatre défauts du même commit — cc663d8d — et le même
accident : un renommage passé plus large qu'il ne devait, qui a mordu au-delà
des identifiants qu'il visait.

Ce que le renommage a emporté
  L'import. verification/relais.ts appelait apps/relais/src/chargeJwt.ts, qui
  n'a jamais existé : composerFcm et CANAUX_ANDROID vivent dans charge.ts. Un
  renommage de la variable locale « charge » en « chargeJwt » avait suivi la
  chaîne jusque dans le chemin du module.

  Le champ de clé. Le contrat de fcm.ts dit « clePem » ; l'appel construisait
  « clePemFcm ». tsc n'y voyait rien : un import dynamique n'est vérifié que
  contre la forme qu'on lui déclare à la main, et cette forme portait la même
  faute. Le contrôle passait donc la compilation pour échouer à l'exécution,
  sur une clé indéfinie.

  Des valeurs, et non plus des noms. « urgence: "mobAndroid" » et
  « urgence: "infoAndroid" » n'appartiennent pas au type Urgence :
  composerFcm retombait sur la branche qui ne réveille pas, et trois
  garanties de priorité et d'expiration échouaient en désignant un défaut qui
  n'était pas là. Les clés de CANAUX_ANDROID avaient subi le même sort.

  Et les libellés, qui sont la sortie lue par un humain : « une mobAndroid
  part en priorité haute » ne veut rien dire.

Une assertion périmée, d'une autre nature
  EM-85 exigeait un 501 — « Android n'est pas encore servi ». C'est le commit
  qui a ajouté FCM qui a laissé cette phrase : il servait Android et
  continuait d'affirmer le contraire.

  Ce qui reste à contrôler n'est plus qu'il refuse, mais comment il refuse
  quand la clé manque. Le relais répond 503 « remise_indisponible » et nomme
  Firebase, parce qu'un refus qui dirait « indisponible » tout court ferait
  chercher la panne du côté d'Apple. Le contrôle vérifie donc les deux : le
  refus, et qu'il nomme le bon côté.

Contrôlé
  492 garanties passent, aucune n'échoue.

Reste ouvert, et sans rapport : la suite s'arrête plus loin sur
« column "nom" does not exist », dans preparation/dossier.ts. Autre
sous-système, autre cause — un écart entre le code et le schéma, pas un
renommage — et corriger demande de savoir quelle colonne était visée.

Co-Authored-By: default avatarClaude Opus 5 <noreply@anthropic.com>
parent f72b9327
Loading
Loading
Loading
Loading