- Shipped
- 7 de septiembre de 2026 a las 3:41 UTC
- Author
- Kamo
- Commit
- 71b3030
Enviar un texto fracasó con "El mensaje no pudo ser enviado. Intenta de nuevo en un momento.". La propia respuesta de Telnyx, del registro de voipserva, fue específica: Telnyx POST /messages falló: El número de teléfono fuente se consideró inválido por el transportista. El remitente almacenado era de 9492989960. Telnyx requiere E.164, por lo que rechazó el envío descarado. La causa raíz es un campo llamado E164 que nada se normalizó. Su javadoc promete "el número en su totalidad, como debe ser exhibido y marcado", pero OrgPhoneNumberService escribió lo que llegó... de una compañía a partir de "phone-number, o de descubrimiento -- directamente en él, recortado sólo. Eso valor luego fluye a ******************* y fuera como "from". Cada capa que aguas abajo confiaba en el nombre del campo. Normalizar en ambos caminos de escritura (salvar y upsertDiscovered) y dónde la instancia portadora en sí se crea o edita, utilizando la existencia E164.normalice ayudante. Se niega en lugar de adivinar, por lo que un número no puede lugar mantiene su texto crudo en lugar de ser mang en silencio en un plausible número equivocado. Dos caminos también discreparon sobre el de un miembro de un miembro: /capabilidad leer sólo CONFIG, que está escrito solo para el titular principal, mientras que el enviar ruta lee la tabla de asignación. Un miembro que sostiene una línea compartida que son no se dijo en las primarias que no tenían número de que enviar mensajes de texto, mientras que un mensaje para ellos habrían tenido éxito. Ambos utilizan ahora un solucionador, y asignando un número escribe la columna heredada para ese miembro también. Retroceder en vivo se reparaba directamente; no hay restos de remitente no E.164 en org.phone,number, bulk.text.provider.instance o member-voip-config.