Cuando la autenticación telefónica falla por configuración, no trates el número como erróneo
Una pregunta pública describe que Firebase Phone Auth falla con "no matching SHA-256 registered" aunque el desarrollador registró la huella de la clave de Play App Signing en la consola de Firebase. No podemos diagnosticar esa plataforma, no representamos a quien preguntó y nada de esto arregla Firebase. Pero la decisión adyacente para un equipo de registro es concreta: cuando el paso de verificación falla por la configuración de la app y no por el número del usuario, ¿qué debe hacer tu flujo de alta? Este artículo usa solo el ejemplo telefónico sintético de cuatro ramas ya verificado para separar un fallo de configuración de un número inválido, muestra las salidas exactas del fixture y propone un manejo propio del llamador que puedes probar antes de decidir si una integración sandbox encaja.
curl https://gridzen.ai/console/api/quickstart/trial \
-H 'Content-Type: application/json' \
-d '{"task": "signup_phone", "scenario": "success"}'El problema: un error de plataforma que parece del usuario
En la pregunta pública, el fallo proviene de la configuración de firma de la app, no del número. Un usuario que escribió un número correcto sigue sin poder terminar. El riesgo para tu aplicación es un manejador que convierte cualquier resultado no exitoso en "teléfono inválido" y rechaza el alta, o uno que reintenta sin fin. Ninguno es correcto. Un error de configuración no dice nada del número, la titularidad ni la alcanzabilidad. Tu decisión es cómo encaminar resultados que no son ni un paso limpio ni un número probadamente inválido. El fixture ofrece ramas con nombre para practicar esa decisión localmente, con Python 3.10+, sin credenciales y sin llamadas de red.
Lo que el fixture implementa realmente
Comportamiento implementado: la función phone recibe una rama (normal, unknown, provider_failure, otp) y devuelve mode, branch, otp_sent, live_line_type_available, state, valid, line_type y next. No envía nada, no llama a ningún proveedor y no verifica firmas. Todas las ramas devuelven mode synthetic_fixture, otp_sent false y live_line_type_available false. Cualquier otra rama lanza UNSUPPORTED_FIXTURE. Salidas esperadas: normal devuelve state simulated, valid true, line_type mobile, next continue_customer_policy. unknown devuelve state unknown, valid null, line_type null, next review_or_existing_otp. provider_failure devuelve state unknown, valid null, line_type null, next bounded_retry_then_review. otp devuelve state unsupported, valid null, line_type null, next customer_otp_provider. El valor mobile es sintético; la ruta de producción gratuita actual no solicita tipo de línea, titularidad, alcanzabilidad ni entrega de OTP.
Escenario hipotético: clasificar un fallo de firma
Escenario hipotético: el alta Android de un equipo pequeño llama a su proveedor OTP existente, y este rechaza la solicitud con un error de huella de app parecido al de la pregunta pública. Diseño de aplicación propuesto, no comportamiento del fixture: tu adaptador clasifica esa respuesta como fallo del proveedor, que ensayas con la rama provider_failure. La salida esperada del fixture es state unknown, valid null, next bounded_retry_then_review. Tu código reintenta un número pequeño y fijo de veces, registra la clase de error para los ingenieros y pasa el alta a revisión en lugar de rechazarla. Como valid es null y no false, nunca se le dice al usuario que su número está mal. Un error de configuración normalmente no desaparece al reintentar, así que el límite importa: el equipo debe corregir la configuración de firma mientras el alta espera en revisión.
Manejo de fallos que corresponde a tu código
El fixture nombra los siguientes pasos; tu aplicación debe implementarlos. Reglas propuestas: trata valid null como ausencia de conclusión, nunca como rechazo. Limita los reintentos de provider_failure y alerta ante errores de configuración repetidos. Para unknown, ofrece revisión o el OTP que ya utilizas. Para otp, next customer_otp_provider significa que tu propio proveedor debe enviar el código; el fixture informa otp_sent false y nunca envía mensajes. Rechaza ramas inesperadas de forma visible, como hace el fixture con UNSUPPORTED_FIXTURE. Mantén este flujo telefónico separado de los registros de permiso locales y callbacks sintéticos del fixture de identidad; son datos de fixture, no permiso comercial real, y su paso recover expira sesiones localmente sin consultar a ningún proveedor.
Lista de aceptación
Antes de una solicitud sandbox, confirma: las cuatro ramas se ejecutan y coinciden con las salidas anteriores; tu manejador nunca rechaza cuando valid es null; los reintentos de provider_failure están acotados y terminan en revisión; los errores de configuración se registran aparte de los errores de entrada del usuario; otp_sent false nunca se muestra como código enviado; live_line_type_available false detiene cualquier lógica que dependa del tipo de línea; una rama no soportada falla de forma visible. Después ejecuta las pruebas de ingeniería con el comando unittest de la guía. Cubren transiciones simuladas, no éxito en producción. La disponibilidad de la ruta real requiere confirmación aparte; las empresas elegibles pueden inscribirse en Basic Lookup gratuito con un límite técnico de 60 solicitudes por minuto, que tampoco devuelve tipo de línea ni titularidad.
Ejecutar el ejemplo sintético comprobado
Descargue y extraiga https://gridzen.ai/downloads/verification-delivery.zip, entre en verification_delivery y ejecute con Python 3.10+. El ejemplo local no hace llamadas de red. Use una base nueva para otra prueba de identidad.
python3 delivery.py phone --branch unknown
python3 delivery.py phone --branch provider_failureFuentes y alcance
https://gridzen.ai/guides/signup-phone-check/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.
Probar por separado tres resultados del sandbox Crear una cuenta para continuar la integración
Una descarga no demuestra una ejecución correcta. Los ejemplos locales y el sandbox en línea se prueban por separado.