Skip to content

Settings and activity

1 result found

  1. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  General » Authentication  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    MOUNIR LOUTFIHI commented  · 

    Subject: Phone Auth - Real numbers failing with error code 39 despite correct configuration (Blaze plan)

    Project ID: washgo-1582e

    We are experiencing a persistent issue with Firebase Phone Authentication on Android (React Native / @react-native-firebase/auth). Test phone numbers work correctly, but real phone numbers consistently fail.

    Error observed:
    [auth/unknown] An internal error has occurred. [ Error code:39 ]

    Steps already taken:
    - Firebase project upgraded to Blaze (Pay-as-you-go) plan
    - App signing key SHA-1/SHA-256 (Play App Signing) added to Firebase Console
    - Upload key SHA-1/SHA-256 also added to Firebase Console
    - OAuth 2.0 Client ID (Android) manually created in Google Cloud Console, linked to the correct package name (com.washgo.mobile) and SHA-1
    - Play Integrity API enabled in Google Cloud Console
    - App Check status confirmed as "Monitoring" (not enforced, so not blocking requests)
    - SMS region policy set to "Allow" for Morocco
    - Google Play Internal Testing release published (versionCode 5), app installed via Play Store (not a development build)
    - Waited several hours between attempts to rule out temporary rate limiting

    Despite all of the above, real phone numbers (e.g. Moroccan numbers, +212...) still fail with error code 39 on every attempt, while test numbers configured in Firebase Console work without issue.

    This appears similar to reported issues:
    - https://github.com/firebase/firebase-js-sdk/issues/8955
    - https://github.com/firebase/flutterfire/issues/11565

    Could you please help us identify whether this is related to an anti-abuse mechanism blocking our project specifically, or another server-side configuration issue? We would appreciate any guidance on how to resolve this for production use.

    Thank you for your help.

    MOUNIR LOUTFIHI shared this idea  ·