App Check modular initialization discards native configuration rejection in 26.4.0

Aperta

#9,395 aperta il 23/10/2026 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Mastersam07 ci sta già lavorando.

Dal 27/10/2026.

#9405 di @Mastersam07 — aperta

Valutazione

Difficoltà: 4/5
Tempo stimato: 3-5 giorni
Idoneità per principianti: 34/100

Tipo di issue: Bug
Chiarezza: Abbastanza chiara
Stato di attività: Attiva
Stack tecnologico: react-native, typescript
Ambito: backend-api-design

Direzione di ricerca

Read packages/app-check/lib/index.ts at v26.4.0 and trace how public initializeAppCheck handles the internal configuration promise and how public token acquisition reports errors. The report describes an offline Jest probe but names no test file or standalone reproduction, so first verify the behavior in the package’s existing tests. Done means setup rejection is handled and exposed through a supported public error boundary while preserving the stated initialization and provider behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

platform: all plugin: app-check type: bug

Issue

The public modular initializeAppCheck in 26.4.0 discards the native configuration promise. An asynchronous configuration rejection is consequently reported as unhandled, even when the consumer observes and catches errors from public token acquisition.

We reproduced this in an offline Jest test with the iOS platform selected. The installed SDK public APIs, provider class, registries and native error wrapping were real code. React Native native hosts, app identity/configuration inputs and the downstream JS token consumer were synthetic. This is not an observed physical-device crash or a claim that Apple App Attest failed.

Reproduction outline

Configure a ReactNativeFirebaseAppCheckProvider for apple.provider: 'appAttest' and invoke public initializeAppCheck with isTokenAutoRefreshEnabled: false.
Have the synthetic native configureProvider operation reject asynchronously after 100 ms. Let native token acquisition reject with provider-not-ready while no provider is configured.
Observe and catch the public token request's rejection. Do not add a process/global rejection handler or call an SDK-private method.
The initializer already returned its handle. Its separate configuration rejection is reported by Jest as unhandled. Catching token acquisition does not contain it. A consumer that keeps the handle and retries only token acquisition does not retry configuration.

Redacted synthetic error signature (not a device log):

NativeFirebaseError: [appCheck/unknown] SYNTHETIC_INITIALIZER_REJECTION

The local matrix had 6 passing controls and 1 failing asynchronous-rejection safety case. Controls covered delayed success, concurrent callers, indefinitely pending setup, late setup completion, pending token work and synchronous setup throw. Those consumer-level controls do not establish native runtime behavior.

Source relationship and expected behavior

The public initializer drops the internal initialization promise. The internal configuration chain returns a promise; public token acquisition calls the native getter separately. The v26 migration guide documents the synchronous handle return. Tagged 27.0.0 source appears to retain this structure; 27 was not installed or tested.

Native setup rejection should be owned immediately, including before a token consumer attaches or after its timeout, and exposed through a supported public error boundary. We are seeking a supported correction or public API that:

exposes settled setup failure through token acquisition or a documented readiness/error boundary while preserving synchronous modular initialization if intended;
documents whether failed setup can be retried safely through public APIs and prevents duplicate setup while pending;
preserves fail-closed pending providers, the selected App Attest provider and disabled native automatic refresh, including error handling in the configure-success continuation.

A supported correction compatible with the 26.x integration would be preferred if that line is maintained. We are not proposing error swallowing, internal method calls, a downgrade to preconfiguration debug-provider behavior, or a change to enforcement. If a newer integration line is required, please identify the exact release/API and migration requirements.

This report summarizes an existing offline probe; it does not include a standalone runnable reproduction repository. No credentials, token values, account metadata, app identifiers, private application source or raw logs are included.

References:

Project Files

Only the relevant package versions are shared below. Native project files are not part of this offline reproduction.

Javascript

`package.json`

Relevant dependency excerpt only:

{
  "@react-native-firebase/app": "26.4.0",
  "@react-native-firebase/app-check": "26.4.0"
}

`firebase.json` for react-native-firebase v6

Not applicable: configuration input was synthetic; no account or production configuration is attached.

iOS

`ios/Podfile`

Not applicable to this offline probe. No Pods or native build was executed.

`AppDelegate.m`

Not applicable to this offline probe. The native host was synthetic.