[firebase-auth] Blocking function timeout returns UNKNOWN error code (code 47) instead of a dedicated timeout code

[Ortes]

Description

When a Firebase Auth blocking function (e.g. beforeUserCreated) times out, the Android SDK throws an error with code UNKNOWN (error code 47) instead of a dedicated, meaningful error code.

This makes it impossible for developers to programmatically distinguish between a genuine internal error and a blocking function timeout, leading to hours of debugging.

Steps to Reproduce

1. Set up a beforeUserCreated blocking function that takes longer than the allowed timeout.
2. Call createUserWithEmailAndPassword (or any auth method guarded by the blocking function) from an Android app.
3. Observe the exception: it surfaces as UNKNOWN / error code 47 with a generic message like "An internal error has occurred."

Expected Behavior

A dedicated error code (e.g. BLOCKING_FUNCTION_TIMEOUT or similar) should be returned so that developers can handle this case explicitly.

Actual Behavior

The error is surfaced as UNKNOWN (error code 47):

Error code: 47
Message: An internal error has occurred.

From Flutter/FlutterFire (where this was originally reported):

[firebase_auth/unknown] An internal error has occurred. [ Error code:47
FirebaseAuthException
Firebase Auth error code: unknown
Firebase Auth error message: An internal error has occurred. [ Error code:47

Context

This was reported on the FlutterFire repository: firebase/flutterfire#18022

The FlutterFire maintainer confirmed that error codes and messages are passed through as-is from the native Android SDK, and recommended opening this issue upstream to request a dedicated error code for blocking function timeouts.

A dedicated error code would benefit all Firebase Auth consumers on Android (native and cross-platform via FlutterFire, React Native Firebase, etc.).

Platform

• Android (Firebase Auth Android SDK)
• Also surfaced via FlutterFire (Flutter wrapper)

[lehcar09]

Hi @Ortes, thank you for reaching out. I tried reproducing the issue, however, I can't seem to reproduce the error.

Here's the code for beforeUserCreated I used

exports.beforeUserCreated = beforeUserCreated((event) => {
  const user = event.data;
  const suffix = "@example.com";

  if (user.email.toLowerCase().endsWith(suffix.toLowerCase())) {
    throw new HttpsError("invalid-argument", "Unauthorized email");
  }
});

And here's the response I got for triggering the error:

createUserWithEmail:failure
com.google.firebase.FirebaseException: An internal error has occurred. [ BLOCKING_FUNCTION_ERROR_RESPONSE:HTTP Cloud Function returned an error: {"error":{"message":"Unauthorized email","status":"INVALID_ARGUMENT"}} ]

Am I missing anything? By any chance can you share a runnable MCVE to help us investigate the issue? Thanks!

[Ortes]

Hi thanks for the reply, can you try with an await that last 30s in the beforeUserCreated function?

[lehcar09]

Hi @Ortes, I added the timeout for 30s, and still getting the error message.

Can you share the Firebase SDK version you're using? I'm using the Firebase version 34.10.0.

[google-oss-bot]

Hey @Ortes. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[Ortes]

Hi @lehcar09, sorry for the late reply — I'm using Firebase Android BOM 34.7.0 (via firebase_core Flutter plugin 4.4.0).

To clarify what I meant in my previous message: the issue is not an await inside the function body. The actual root cause is a cold start problem.

When there is no warm instance available, my blocking function takes more than 10 seconds to spin up before it even starts executing. That startup delay alone exceeds the blocking function timeout, which triggers the UNKNOWN (code 47) error — the function never actually runs.

I understand this is a fairly specific edge case, but it took me a long time to figure out the root cause precisely because the error code gives no indication of what actually happened. A dedicated error code for this scenario would make debugging significantly faster for developers hitting the same issue.