- Expédié
- 7 septembre 2026 à 03:41 UTC
- Auteur
- Kamo
- Commite
- 71b3030
L'envoi d'un texte a échoué avec "Le message n'a pas pu être envoyé. Essayez à nouveau dans un moment..." La propre réponse de Telnyx, tirée du journal voipservice, était spécifique : Telnyx POST /messages en échec: Le numéro de téléphone source a été jugé nul par le transporteur. L'expéditeur stocké était le suivant : '9492989960'. Telnyx exige E.164, de sorte qu'il a rejeté l'envoi pur et simple. La cause des racines est un champ nommé 'e164' que rien ne s'est jamais normalement normalisé. C'est du javadoc promet "le nombre en entier, comme il doit être affiché et composé", mais OrgPhoneNumberService a écrit tout ce qui est arrivé -- de la part d'un transporteur à partir de l'identifiant, ou de la découverte -- directement dans celui-ci, paré seulement. Que la valeur s'écoule alors vers - et out en "à partir de". Chaque couche en aval a fait confiance au nom du champ. Normaliser sur les deux chemins d'écriture (sauver et upsertDécoré) et où le l'instance de support elle-même est créée ou éditée, en utilisant les E164.normaliser l'aide. Il refuse plutôt que deviner, donc un nombre il ne peut pas place place maintient son texte brut au lieu d'être silencieusement emmêlé dans un plausible un mauvais nombre. Deux chemins étaient également en désaccord sur le numéro d'un membre: /capacitabilité lire seulement MEMBER-VOIP-CONFIG, qui est écrit pour le titulaire principal seul, tandis que envoyer chemin lit la table d'affectation. Un membre titulaire d'une ligne commune, il est n'a pas été informé qu'ils n'avaient pas de numéro à envoyer, tandis qu'un envoi pour elles auraient réussi. Les deux utilisent maintenant un résolveur, et attribuer un numéro écrit la colonne d'héritage pour ce membre aussi. Les rangées en direct ont été réparées directement; aucun expéditeur non-E 164 ne reste dans org-phone-number, bulk-text-provider-instance ou member-voip-config.